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Procede et systeme d'etablissement automatique d'un modele global de 

simulation d'une architecture 

L'invention concerne un procede et un systeme d'etablissement d'un 
5 modele global de simulation d'une architecture. Plus particulierement, 
l'invention concerne un procede de configuration et un systeme dit 
"Configurateur" pour mettre en ceuvre le procede. 

Avec I'accroissement de la complexite des systemes hardware, il faut 
pouvoir traiter, pour la verification de systemes ou circuits integres en projet, 
10 des configurations rassemblant de plus en plus de modeles ecrits en langage 
de description du materiel, par exemple, de type HDL (tels que VHDL ou 
Verilog, les plus utilises) et en langage de haut niveau de type HLL (tels que 
C ou C++), ces langages decrivant, d'une part, les elements constitutifs du 
materiel (hardware) et, d'autre part, les modeles constitutifs de 
15 I'environnement de simulation. 

Nous allons referer comme "Configuration" un ensemble de modeles 
logiciels d'elements dits "Composants" constituant un modele global de 
simulation. 

L'invention est utile dans la verification de la conception des ASICs 
2 0 par simulation de leur fonctionnement, par exemple, dans un environnement 
identique a ou tres proche de leur utilisation finale, le procede de 
configuration permettant le choix de composants et de leurs modeles 
logiciels parmi une pluralite de modeles disponibles pour la constitution de 
configurations de simulation. 
2 5 Dans I'art anterieur les configurations sont rigides et traditionnellement 

preparees "a la main" a I'aide d'editeurs de texte ou d'editeurs graphiques, 
d'apres une liste predefinie de configurations envisageables. Chaque 
modification dans le modele en langage HDL necessite des corrections 
manuelles a repercuter dans I'ensemble des configurations. Cela arrive 
30 plusieurs fois au cours du deyeloppement d'un ASIC et constitue une source 
d'erreurs et de difficultes de modification entrainant des retards de 
realisation. Les modifications de configuration sont souvent sources d'erreurs 
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difficiles a trouver, la taille de certaines configurations pouvant atteindre des 
dizaines de milliers de lignes difficilement manipulables manuellement. 

Le temps d'ecriture et de mise au point d'une configuration peut etre 
5 tres long, rendant difficile la generation et Introduction de configurations 
nouvelles dans I'environnement De ce fait, dans le cas d'un environnement 
contenant beaucoup d'elements pour lequel il est difficile de prevoir a 
I'avance toutes les configurations utiles, on renonce souvent a I'utilisation de 
certaines variantes de configurations facilitant le deverminage (configurations 

10 ciblees simplifies, par exemple). 

Ces difficultes sont accentuees dans les environnements de co- 
simulation, de plus en plus utilises, ou les modeles proviennent de differentes 
sources et sont ecrits en langages de programmation de haut niveau (HLL) 
tels que C, C++, ou en langages de descriptions du materiel (HDL), tels que 

15 VERILOG ou VHDL. Pour le meme composant de la configuration, il existe 
souvent plusieurs modeles (ex : fonctionnel en langage de programmation de 
haut niveau, comportementat en HDL, synthetisable HDL, etc..) qu'on 
aimerait utiliser de maniere transparente selon les besoins. 

De plus, les modeles a connecter presentent souvent, au niveau des 

2 0 interfaces en vis-a-vis, des differences necessitant des modules 
d'adaptation. C'est le cas, par exemple, de circuits avec des interfaces 
d'entree-sortie sophistiques pour lesquels, dans un premier temps, on simule 
le niveau logique du protocole, le niveau physique etant developpe vers la fin 
du projet. Le choix de modules d'adaptation pour des variantes d'interfaces 

2 5 HDL correspondant aux differentes phases de developpement du projet 
constitue un degre de liberte supplemental qui complique d'avantage 
encore I'ecriture des configurations. 

Une autre difficulty vient du fait que les modeles mixtes de type HDL 
(par exemple, VERILOG ou VHDL) / HLL (par exemple, C++) developpes 

30 separement, doivent etre mis a jour de maniere coherente. Dans le cas d'une 
gestion non automatisee, c f est une source potentielle d'erreurs. 
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La presente invention vise a limiter un ou plusieurs de ces 
inconvenients. 

A cet effet, Tinvention concerne tout d'abord un procede 
d'etablissement automatique, au moyen d'un systeme de traitement de 
5 donnees associe a un programme dit Configurateur, pour constituer un 
modele global de simulation d'une architecture comprenant des modeles de 
circuits integres en developpement pouvant constituer, a I'aide du 
Configurateur automatique, une machine ou une partie d'une machine et des 
modeles d'environnement de simulation, permettant de tester et de verifier le 

10 circuit en developpement, d'un fichier de definition de configuration de 
composants de ['architecture, ces composants constituant des blocs 
fonctionnels determines de description des fonctionnalites de circuits integres 
ou de parties de circuits integres, les composants etant choisis par 
I'utilisateur dans une bibliotheque de differents types de composants et une 

15 bibliotheque de composants d'environnements pour constituer le modele 
global de ('architecture repondant a la specification fonctionnelle definie dans 
le fichier de definition de configuration et conforme a la specification de 
I'architecture du modele global specifie par un fichier de description de 
1'architecture, procede caracterise par le fait qu'il comporte les etapes 

2 0 suivantes : 

- lecture du fichier de description d'architecture du modele 
global et memorisation, dans une table de composants et de regies de 
connexion, dans une table de regies de coherence de connexions et dans 
une table de formatage de fichiers source, des informations relatives a 

2 5 I'ensemble des configurations possibles, chaque composant obtenant un 
nom identifiant, de fagon non equivoque, sa position dans 1'architecture, ainsi 
qu'un type parmi plusieurs types (Composants actifs, Blocs de Monitoring et 
de Verification, Blocs intermediates, Blocs systemes et Blocs Globaux), 

- instanciation des composants, specifies dans le fichier de 
30 definition de configuration par I'utilisateur-concepteur au moyen d'une liste de 

composants presents designes par leurs nom et type et comportant des 
parametres ou faisant appel a des procedures, le fichier de definition de la 
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configuration comprenant un fichier de selection des composants et de leur 
type et des indications supplementaires optionnelles concernant le type 
d'interface et le serveur concerne par la configuration a generer par le 
Configurateur, et memorisation des informations correspondantes dans une 
5 table de connexion des instances, 

- connexion topologique des instances et memorisation des 
informations correspondantes dans une table de connexion des instances. 

- connexion physique des signaux d'interface, au niveau de 
chaque instance des composants, par application d'expressions 

10 regulieres, memorisees dans la table de composants et de regies de 

connexion, portant sur le nom des signaux constituant une table de 
cablage, 

- utilisation de la table de connexion des instances, de la table 
de cablage et de la table de formatage pour generer automatiquement des 

15 fichiers source de type HDL et de type HLL du modele global de simulation, 
correspondant a la configuration specifiee par le fichier de definition de 
configuration. 

Selon une autre particularite du procede, le systeme Configurateur 
transmet aux parties de type HLL de chaque composant des informations 
20 sur: 

- le nom du composant, 
le type de I'instance, 

le chemin HDL, a savoir le nom hierarchique du composant dans la 
description du modele. 
2 5 Selon une autre particularite du procede, le fichier de definition de 

configuration comporte en plus un mot-cle indiquant le nom ou numero du 
serveur sur lequel se trouve instancie un composant dans le cas d'une 
utilisation du procede sur un systeme multi-serveur. 

Selon une autre particularite du procede, dans le cas d'une utilisation 
30 multi-serveur, le systeme Configurateur execute les §tapes suivantes : 

- decoupage de la Configuration en plusieurs parties (de type 
HDL et de type HLL) en triant les composants de type HDL 
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et les objets de type HLL selon leurs appartenances aux 
serveurs, 

- generation des composants de type HDL peripheriques 
servant a I'envoi et la reception des signaux entre les 

5 parties de la configuration, 

- duplication des Blocs Globaux par le systeme Configurateur 
et instanciation des Blocs Globaux dupliques sur chaque 
serveur, 

- generation des parties de type HLL servant de support de 
10 communication entre les serveurs. 

Selon une autre particularite du procede, la connexion automatique 
entre les composants par le systeme Configurateur comprend plusieurs 
phases : 

- une phase topologique de haut niveau realisant la selection 
15 des composants et leurs positionnements respectifs, 

- une phase de cablage realisant la connexion effective entre 
les composants, cette phase generant comme resultat une 
table de cablage associant les signaux connectes 
ensemble, au nom unique du fil les connectant, 

2 0 - une phase de generation des fichiers sources de type HDL 

etde type HLL. 

Selon une autre particularite du procede, la phase de cablage est 
effectuee par le systeme Configurateur selon les trois etapes suivantes : 

a. les Blocs Globaux et les Blocs Systeme sont connectes en premier a 

2 5 tous les composants, 

b. viennent ensuite les connexions des signaux entre les autres 
composants, 

c. a la fin du cablage, une passe supplemental permet de connecter 
les signaux restant non connectes de chaque composant a des 

3 0 signaux predetermines pour assurer un etat stable et determine, le 
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systeme Configurateur generant alors des configurations partielles 
comprenant un sous-ensemble de ['architecture. 

Selon une autre particularite du precede, les signaux predetermines 
sont les signaux du Bloc Systeme correspondant au composant. 
5 Selon une autre particularite, le fichier de description de I'architecture 

du modele global comprend les modeles de simulation des Blocs globaux et 
des Blocs Systeme, ces deux types de composants etant connectes entre 
eux et gerant des signaux d'environnement. 

Selon une autre particularite, les Blocs Systeme sont connectes aux 
10 autres composants et leur fournissent des signaux systeme qui leur sont 
specifiques. 

Selon une autre particularite du procede, le systeme de traitement de 
donnees effectue un controle de conformite des connexions en comparant la 
table de connexion des instances reelles entre blocs avec la table de regies 

15 de coherence de connexions. 

Selon une autre particularite du procede, le systeme de traitement de 
donnees compare les connexions physiques entre les composants, a la table 
de regies de coherence de connexions, pour detecter des incompatibilites 
entre extremites de connexions entre les composants, et, en pareil cas, il 

2 0 specifie, et ajoute, dans la table de connexion des instances, un composant 
adaptateur insere dans la connexion consideree. 

Selon une autre particularite, le fichier de definition de configuration 
comprend des informations, specifiees par un attribut, concernant I'utilisation 
de composants adaptateurs avec les instances des Composants actifs, dont 

2 5 les connexions sont comparees a la table de connexion des instances, pour 
detecter des incompatibilites entre extremites de connexions entre les 
composants, et, en pareil cas, il specifie, et ajoute, dans la table de 
connexion des instances, un autre composant adaptateur insere dans la 
connexion consideree. 

30 Selon une autre particularite du procede, le systeme de traitement de 

donnees selectionne certaines des connexions entre composants de la table 
de regies de coherence de connexions et specifie, et ajoute, dans la table de 
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connexion des instances, des connexions supplementaires constituant des 
derivations aboutissant a des modeles supplementaires respectifs, 
representant des outils de surveillance des connexions. 

Selon une autre particularite du procede, dans la phase de generation 
5 des fichiers sources, le systeme Configurateur genere les fichiers source en 
langage HDL et en langage HLL en s'appuyant sur le contenu de la table de 
composants et de regies de connexion, la table de regies de coherence de 
connexions, la table de formatage de fichiers source, la table de connexion 
des instances et la table de cablage. 

10 Selon une autre particularite du procede, le systeme de traitement de 

donnees effectue un traitement par le systeme Configurateur, pour chaque 
variante de configuration, pour obtenir plusieurs modeles de simulation 
correspondant a la meme specification fonctionnelle, mais ecrits en une 
description comportant differents melanges des langages de niveaux 

15 differents (HDL, HLL). 

Selon une autre particularite du procede, le systeme de traitement de 
donnees etablit la specification fonctionnelle du modele global de simulation 
dans un format informatique compatible avec un langage de programmation 
de haut niveau (HLL) et en format compatible avec un langage de description 

2 0 du materiel (HDL). 

Selon une autre particularite du procede, le fichier de definition de 
configuration comprend, pour chaque composant, au moins une partie en 
langage de type HDL, ladite partie en langage de type HDL fournissant une 
interface vers d'autres modeles. 

2 5 Selon une autre particularite du procede, les modeles comprenant une 

partie en langage de type HLL comprennent des adaptateurs d'interface. 

Selon une autre particularite, le systeme Configurateur choisit chaque 
modele d'adaptateurs d'interface en fonction de la table de regies de 
coherence de connexions. 

30 Selon une autre particularite du procede, les connexions des signaux 

physiques sont specifies par des "Ports ', chaque port etant une selection 
arbitraire des signaux de Interface de type HDL d'un composant a I'aide des 
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expressions regulieres portant sur les noms de ces signaux, et etant 
constitue de paires expression reguliere / expression de substitution, ces 
expression etant appliquees successivement au nom de chaque signal de 
I'interface de type HDL, et, si la substitution finale est identique pour deux 
5 signaux, ces derniers sont connectes entre eux, la connexion etant 
memorisee dans la table de cablage. 

Selon une autre particularity du procede, chaque adaptateur 
d'interface etant partage entre plusieurs modeles connectes sur le meme 
port, un seul de ces modeles emet des signaux sur ledit port. 

10 Un autre but de Pinvention est de proposer un systeme Configurateur 

qui permette de pallier un ou plusieurs des inconvenients precedents. 

Ce but est atteint par le systeme de traitement de donnees pour 
Petablissement automatique d'un modele global de simulation d'une 
configuration de blocs fonctionnels determines, mutuellement relies par des 

15 connexions d'interfonctionnement, pour constituer le modele global de 
simulation d'une architecture comprenant des modeles de circuits integres en 
developpement pouvant constituer une machine repondant a la specification 
fonctionnelle d'une configuration, systeme caracterise par le fait que le 
systeme de traitement de donnees utilise un programme Configurateur qui 

2 0 comprend des moyens de realiser une simulation du cablage par ['application 
d'expressions regulieres memorisees, d'utiliser un fichier de definition de 
configuration en langage de haut niveau, une table de composants et de 
regies de connexion decrivant les proprietes (type, Interfaces de type HDL, 
ports, constructeurs d'objets de classes HLL, etc..) des composants logiciels 

2 5 de simulation du circuit, une table de regies de coherence de connexions en 

langage de haut niveau (HLL), des moyens d'instancier les elements 
resultants du fichier de definition de configuration, un generateur du code 
HLL qui combine les parametres des composants avec les regies de 
connexion. 

3 0 Selon une autre particularity du systeme, il existe au moins cinq types 

de composants : les Composants actifs, les Blocs de Monitoring et de 
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Verification, les Blocs intermediates, les Blocs Systeme et les Blocs 
Globaux. 

Selon une autre particularity du systeme, il est agence pour effectuer 
un controle de conformity des connexions en comparant la table de 
5 connexion des instances avec une table de regies de coherence des 
connexions physiques entre les modeles choisis des blocs constituant le 
modele global. 

Selon une autre particularity du systeme, il est agence pour comparer 
la table de connexion des instances reelles entre blocs a la table de regies 

10 de coherence des connexions, pour detecter des incompatibility s entre 
extremites de connexions entre blocs, et, en pareil cas, pour specifier, et 
ajouter, dans la table de regies de coherence des connexions reelles, un bloc 
fonctionnel adaptateur insere dans la connexion consideree. 

Selon une autre particularity du systeme, la table de composants et de 

15 regies de connexion, comprenant les proprietes des composants, contient 
des parametres globaux communs a tous les types de composants et se 
presente sous forme d'une table repartie suivant une ou plusieurs tables, 
associatives ou non, dont les entrees sont des noms designant I'ensemble 
des modeles possibles pour un meme composant. 

20 Selon une autre particularite du systeme, les tables associatives 

peuvent contenir la description, soit sous forme de suites de parametres, ou 
bien sous forme de references a des procedures qui generent les valeurs 
requises, les entrees de ces tables associatives etant des noms designant 
I'ensemble des modeles possibles pour un meme composant et formant une 

2 5 chaTne de caracteres contenant des identificateurs speciaux predetermines, 
substitues par les valeurs calculees par le systeme Configurateur. 

Selon une autre particularite du systeme, au moins trois selecteurs 
indiquent Tinstance a prendre en compte, cette derniere etant transmise 
comme parametre a un constructeur d'un objet HLL : 

30 - un premier selecteur indique I'instance courante, 

- un deuxieme selecteur precise ['instance connectee a I'autre 
extremite du port, 
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- un troisieme selecteur indique I'instance composee 
correspondant au Composant actif contenant le port 
d'observation. 

Selon une autre particularity du systeme, le systeme Configurateur 
5 utilise une ou plusieurs tables de regies de coherence de connexions, qui 
represented les regies d'interconnexion entre les composants et d'insertion 
des composants intermediates, une ou plusieurs tables de composants et de 
regies de connexions, qui represented les regies de connexion niveau 
systeme et les regies de generation de connexions entre les signaux, et une 
10 ou plusieurs tables de formatage de fichiers source, qui represented les 
regies de generation des instances des objets de type HLL. 

Selon une autre particularity du systeme, le systeme Configurateur 
utilise : 

- une classe de base en HLL permettant d'identifier de fagon univoque 
15 chaque objet instancie et d'interroger la configuration, 

- des moyens de generation et d*instanciation automatique des Blocs 
Systeme, 

- des moyens des tableaux associant les signaux connectes ensemble 
au nom unique du fils connectant, 

2 0 - des moyens d'utiliser un tableau de formatage pour generer les 

fichiers sources en HDL et HLL. 

Selon une autre particularity du systeme, Toperateur specifie 
fonctionnellement, dans la plus large mesure possible, la configuration dans 
le langage de plus haut niveau et il complete la specification fonctionnelle par 

2 5 les composants en langage de plus bas niveau. 

Selon une autre particularity du systeme, les entrees suivantes du 
hachage definissent le Type du composant (par exemple DUT (modele HDL), 
XACTOR (transactor), MONITOR, VERIFIER ou autres) et, a chaque Type 
de Composant, correspond un hachage compose a son tour des entrees 

30 suivantes : 

- une premiere entree ReqModule - contient le nom du module HDL 
du composant et le nom du fichier source correspondant, 
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- une deuxieme entree Connect - est la definition de la methode de 
selection des signaux faisant partie d'un Port, cette description 
etant composee d'une suite d'entrees indexees par le nom du 
Port ; a chaque nom de Port, le configurateur associe un tableau 
5 d'expressions regulieres et un pointeur sur une procedure de 

connexion des signaux qui gere I'application de ces expressions 
aux noms des signaux de interface du composant. 
Selon une autre particularity du systeme, la structure generique des 
Composants actifs comprend un Bloc contenant la description HDL et un 
10 Bloc en HLL, fournissant les chemins d'acces aux ressources HDL et, le cas 
echeant, une description du bloc en HLL, ('ensemble des signaux du bloc 
HDL constituant I'interface du Bloc englobant, formee, d'une part, de Ports, 
qui sont des selections logiques arbitraires des signaux d'une interface et, 
d'autre part, d'adaptateurs d'interface, qui sont les parties logicielles 
15 assurant, sur chaque Port, la communication bi-directionnelle entre les 
parties en HLL et celles en HDL, les adaptateurs d'interface etant choisis par 
le systeme Configurateur. 

Selon une autre particularite du systeme, les Ports sont specifies sous 
forme d'expressions regulieres, qui servent a la fois a selectionner les sous- 
20 ensembles de signaux a connecter et a definir les regies de connexions. 

Selon une autre particularite du systeme, le systeme Configurateur 
genere des Composants dits de Transfert qui sont inseres de chaque cote de 
la coupure sur les serveurs, ces composants etant simplement des fils pour 
les entrees et des registres pour les sorties. 
25 Les composants a modele elementaire qui sont partages entre les 

Composants a Modele Compose ou les Blocs Globaux appartenant aux 
differents serveurs sont automatiquement dupliques par le systeme 
Configurateur et instancies sur chaque serveur. 

30 L'invention sera mieux comprise a I'aide de la description suivante 

d'un mode prefere de mise en oeuvre du procede de ('invention, en reference 
aux dessins annexes, sur lesquels : 
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- la figure 1 represente, sous forme tres schematique, un exemple 
cTarchitecture du modele global de simulation pour un circuit 
integre (ASIC) en developpement appele BRIDGE (12) ; 

- les figures 2a a 2d sont des diagrammes illustrant les differentes 
composantes du systeme Configurateur et les etapes de mise en 
oeuvre de ces composantes dans le procede de I'invention ; 

les figures 3a a 3c represented differents stades de modelisation 
d'un circuit a I'aide d'un modele mixte de type HDL (VERILOG ou 
VHDL) et de type HLL (C++) ; 

- la figure 4 represente la structure generique d'un Modele 
elementaire ; 

la figure 5 represente la structure generique d'un Modele 
Compose ; 

la figure 6 decrit la correspondance entre les tables de la 
description du systeme configurateur sur les figures 2a a 2d et les 
tables de la mise en oeuvre du procede de I'invention ; 

- les figures 7a a 7k represented schematiquement les differents 
modeles des composants avec leurs variantes d'interfaces et de 
niveau de description necessaires pour les configurations relatives 
a 1'architecture de I'exemple de la figure 1 ; 

- les figures 8a a 8e represented les configurations successives de 
I'architecture aboutissant a une constitution du modele donnee 
dont le modele final correspond a celui de la figure 8e et pour 
lequel tous les modeles de type HDL du circuit en projet sont 
disponibles, ce modele final correspondant a la configuration. 

la figure 8f represente la repartition de la configuration de 
simulation du modele de la figure 8a, par exemple sur deux 
machines. 

L'invention concerne un systeme dit "Configurateur" et le procede de 
configuration mis en oeuvre par le systeme. 
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Un modele global de simulation est typiquement compose d'un ou 
plusieurs modeles de circuits integres testes (DUT) entoures de modeles qui 
creent un environnement de test et verification. Ces modeles creent des 
stimuli complexes et regoivent des reponses complexes du modele teste. 
5 Ces composants peuvent etre des transactors (XACTORS) - des modeles 
possedant generalement une interface programmatique (API) permettant un 
pilotage par des tests externes au modele, ces tests etant ecrits 
generalement en langage de haut niveau (HLL). 

L'environnement de verification peut contenir aussi des composants 

10 dits Bloc de Monitoring (MONITOR) et des composants dits Bloc de 
Verification (VERIFIER). Ces composants n'interviennent pas directement 
dans I'echange de signaux entre les autres constituants du modele global de 
simulation mais servent a les observer et a interpreter. Les Blocs de 
Monitoring (MONITOR) servent de support d'analyse pour les tests, ils 

15 possedent des interfaces programmatiques (API) pour signaler des 
evenements observes sur les signaux de modele global. Les Blocs de 
Verification (VERIFIER) sont des composants qui possedent une 
specification de reference de fonctionnement de modele teste et, en 
observant les signaux du modele global de simulation, sont capables de 

2 0 verifier le bon fonctionnement du modele. 

La figure 1 represente un exemple d'architecture d'un systeme de 
circuit integre en developpement dont on veut, dans une premiere etape, 
mettre au point le modele global de simulation correspondant a la figure 8c, 

2 5 choisie pour illustrer le nombre le plus important de mecanismes mis en 
ceuvre par le configurateur. II doit etre clair que les etapes des figures 8a, 8b 
pourraient etre d'abord executees selon la disponibilite des modeles et les 
objectifs de verification. Le modele final souhaite est celui correspondant a la 
figure 8e. L'architecture est constitute d'un processeur (CPU) communicant 

30 par une passerelle (BRIDGE) avec une memoire systeme (MEMORY) et des 
entrees sorties (I/O). Le modele auquel aboutit le systeme "Configurateur" de 
Pinvention est constitue d'un composant processeur CPU de type XACTOR 
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relie par une interface de type "fbus_p" a un bloc intermediaire (fbus_xchg) 
101 ayant une interface de type different. Un autre bloc intermediaire 
(fbus_xchg) 102 figures 8b et 8c relie le premier bloc intermediaire 101 a un 
composant de type passerelle (BRIDGE) de type DUT_CORE qui 
communique, d'une part avec un modele majoritairement en langage de type 
HDL d'une memoire (MEMORY) de type DUT, d'autre part avec un modele 
majoritairement en langage de type HDL d'une entree/sortie (I/O) de type 
DUT et enfin avec un bloc systeme (SYS_BRIDGE). 

Le systeme "Configurateur" de ('invention gere la connexion 
d'elements logiciels de simulation appeles composants pour les besoins de 
la simulation des circuits hardware. 

II existe au moins 5 classes de composants : 

- Les "Composants actifs" (voir ci-apres) ; 

- Les "Blocs de Monitoring et de Verification" (voir ci-apres) ; 

- Les "Blocs intermediates" (voir ci-apres) ; 

- Les "Blocs Systeme" (voir ci-apres) ; 

- Les "Blocs Globaux" (voir ci-apres et 1 de A2). 

Chaque type de composant peut posseder plusieurs variantes de 
realisation d'un meme element, differenciees par le niveau de description 
(voir ci-apres) ou par les signaux sur les interfaces (voir ci-apres). Chaque 
type de Composant peut etre decrit a plusieurs niveaux de details 
(fonctionnel, comportemental, portes, etc..) en langage de type HDL, tel que 
VERILOG ou VHDL, ou en langage de haut niveau (HLL), tel que C ou C++ 
complete d'une interface de type HDL. 

Plusieurs niveaux de descriptions peuvent coexister pour decrire des 
fonctionnalites similaires et avoir des interfaces de type HDL similaires mais 
pas forcement identiques. Certaines descriptions peuvent avoir plus de 
fonctionnalites, et les interfaces de type HDL peuvent contenir des jeux de 
signaux completement differents. 
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Les composants sont connectes selon un schema predetermine 
considere fixe pour chaque execution du systeme Configurateur. Ces 
connexions sont definies par 1'architecture du modele global de simulation et 
specifiees par le fichier de description d'architecture (FDARCH) (voir 
5 annexes A1-A5). 

Chaque instance d'un composant dans ce schema obtient un nom ou 
label qui identifie de fagon non equivoque la position du composant et son 
type. 

Le fichier de definition de la configuration (FCONF) fournit une 

10 description synthetique de la variante de Configuration a generer par le 
systeme Configurateur. Seuls les composants principaux (Composants 
Actifs, Blocs de Monitoring et Blocs de Verification) y sont mentionnes avec 
les types de modeles souhaites. Les autres composants (Blocs Globaux, 
Blocs Systeme et Blocs Intermediates) seront instancies automatiquement 

15 par le systeme configurateur. 

Parmi les differents types de composants, les "Composants Actifs" 
constituent le sous-ensemble des objets explicitement designes dans le 
fichier de configuration (FCONF) et qui echangent des stimuli en emission et 
reception avec leur environnement. 

20 Parmi les differents types de composants, les "Blocs de Monitoring et 

Verification" constituent le sous-ensemble des objets, explicitement designes 
dans le fichier de configuration (FCONF), qui ne font que recevoir des 
informations de leur environnement. Ms sont utilises a des fins d'observation 
et de Verification (MONITOR, VERIFIER). La granularite de traitement de 

2 5 ces modeles est I'evenement qui rend compte des changements de valeurs 
des signaux de controle et des echanges arbitraires de donnees. 

Tous les autres Composants constituent des composants dits 
implicites, qui sont geres et instancies de fagon automatique par le systeme 
configurateur, en fonction des parametres du fichier de configuration 

30 (FCONF) (type de composants explicites, type d'interface, ...). 

Les composants peuvent etre connectes entre eux directement ou par 
I'intermediaire de composants d'adaptation externe dits "Blocs 
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Intermediaires" definis et declares specialement a cet effet. lis sont souvent 
utilises, comme nous le verrons par la suite, lors des phases successives de 
developpement pour completer les parties manquantes du design. 

Le systeme Configurateur peut inserer ainsi un ou plusieurs blocs 
5 intermediaires pour connecter deux composants actifs. 

Les composants dits "Blocs Systemes" sont associes aux autres 
composants pour leur fournir les signaux d'environnement qui leur sont 
specifiques. Ces composants encapsulent, au niveau de chaque interface, 
I'ensemble des signaux systeme ne participant pas a la connexion entre les 

10 autres composants. Les "Blocs Systemes" sont eux-memes connectes aux 
"Blocs Globaux" et gerent I'ensemble des signaux d'environnement : les 
signaux d'horloge et de controle general (clock, reset, powergood, 
diagnostic), qui peuvent etre eventuellement transformes pour les adapter au 
besoins du bloc actif correspondant (changement de polarite, retard etc.), 

15 ainsi que les signaux specifiques, differents pour chaque instance particuliere 
du composant actif concerne, par exemple les signaux codant le numero de 
module ou le mode de fonctionnement du composant, etc... Ces derniers 
sont geres par des parametres fournis par le systeme Configurateur aux 
instances de modeles des composants generes. Si, pour un Composant 

2 0 donne, le Bloc Systeme n'est pas necessaire (ce qui est indique par les 
tables de description de la configuration), il sera relie directement aux Blocs 
Globaux (cf. 1 de A2). 

Le fichier de configuration (FCONF) peut contenir des informations 
supplementaires specifiant des blocs intermediaires a utiliser en association 

2 5 avec les instances des composants actifs. Ainsi, I'utilisateur peut influencer le 
choix du composant intermediaire, ou lever rambiguite, dans le cas de 
plusieurs choix possibles. Les connexions ainsi obtenues sont comparees a 
la table de regies de coherence de connexions (TRCOH) pour detecter des 
incompatibilites entre extremites de connexions entre les composants et, en 

30 pareil cas, choisir et ajouter, dans la table de connexion des instances 
(TCINST), encore un composant adaptateur (Bloc Intermediaire) insere dans 
la connexion consideree. 
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Le systeme Configurateur s'appuie sur une representation generique, 
telle que decrite sur les figures 3a a 3c, commune a I'ensemble des 
composants declares dans le fichier de description d'architecture (FDARCH) 
5 du modele global de simulation, et comprenant deux parties, de type HDL 
(par exemple VERILOG ou VHDL) et de type HLL (par exemple C++). 

Dans le cas d'un composant decrit completement en langage de type 
HDL (figure 3a), la partie de type HLL est reduite a une instance qui permet 
de signaler sa presence dans la Configuration au cours de la simulation et 
10 qui fournit les chemins d'acces aux ressources de type HDL du composant. 

Pour les composants decrits en langage de type HLL (figure 3c), c'est 
la partie de type HDL qui est reduite au strict minimum, et qui est limitee a la 
description des signaux et registres d'interface. 

Tous les niveaux intermediates entre ces deux extremites sont 
15 possibles et naturellement exploites dans le contexte de processus de 
developpement des circuits ASIC. 

Typiquement, au cours d'un developpement, on commence par un 
modele de type HLL avec une interface de type HDL minimale et, ensuite, on 
passe a des modeles de type HDL de plus en plus complets ecrits par les 
2 0 concepteurs et on termine par les modeles du niveau portes logiques 
synthetises automatiquement a partir de modeles de type HDL. 

Les modeles mixtes sont souvent utilises parce qu'ils permettent une 
simulation precise et efficace en dediant le langage de haut niveau (HLL) aux 
moderations complexes pour lesquelles le langage de type HLL offre une 
2 5 description compacte et rapide a I'execution. Neanmoins, meme pour les 
modeles ecrits majoritairement en langage de type HLL, la partie de type 
HDL peut etre non triviale pour des raisons de pertes de performances dues 
aux changements de contexte de simulation entre, respectivement, les 
parties de type HDL et de type HLL. Un exemple typique est une interface 
30 dont les signaux changent, meme sans activite reelle de transfert de 
donnees. Dans ce cas, il est preferable de traiter les signaux dans la partie 
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de type HDL du modele, et de passer a la partie de type HLL quand les 
donnees sont presentes sur I'interface. 

L'interface d'un composant est I'ensemble de tous les signaux 
presents a sa peripherie. Pour les composants decrits uniquement en 
5 langage de type HDL, cela correspond a l'interface externe de la definition de 
ce composant en langage de type HDL (par ex. VERILOG ou VHDL). Pour 
les composants definis de maniere mixte en langage de types HLL et HDL, 
Tinterface d'un composant est la somme des signaux de tous les modules de 
type HDL utilises a la peripherie de ce composant. 
10 La figure 4 decrit la structure generique des modeles elementaires 

constituant la majorite des composants. Cette structure s'applique 
typiquement, mais pas uniquement, au cas du circuit ASIC en 
developpement, des adaptateurs d'interface, blocs intermediates, blocs 
systeme. 

15 Elle comprend un Bloc englobant note C contenant la description de 

type HDL notee A et le Bloc HLL note B fournissant les chemins d'acces aux 
ressources de type HDL et, le cas echeant, une description du bloc en 
langage de type HLL. L'ensemble des signaux du bloc de type HDL constitue 
l'interface du bloc C. Pour les besoins de connexion entre les blocs nous 

2 0 utilisons la notion de Ports (voir plus loin) qui sont des selections logiques 
arbitraires des signaux d'une Interface. II est possible qu'un signal 
appartienne a plusieurs Ports a la fois. 

Le systeme Configurateur est capable de traiter des modeles dits 
'composes' comprenant une partie en langage de type HLL et incluant 

2 5 d'autres modeles des composants dits 'adaptateurs d'interface'. Les 
adaptateurs d'interface sont des modeles mixtes de types HDL / HLL 
possedant une interface programmatique (API) en langage de type HLL par 
laquelle ils peuvent communiquer avec le modele compose. Les modeles 
composes sont particulierement utiles pour les composants d'environnement 

30 de simulation (par exemple MONITOR, VERIFIER, XACTORS) ou le modele 
doit s'adapter a des signaux presents sur les differentes variantes des 
modeles utilises dans une configuration. 
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La figure 5 decrit la structure generique de modeles composes, utilises 
surtout pour modeliser les constituants de renvironnement de simulation. Vu 
de sa presentation exterieure, le modele compose est identique au modele 
elementaire. A I'interieur, la specification HLL du modele (notee D) 
5 communique avec I'interface exterieure de type HDL a travers les 
adaptateurs d'interface (notes C_Port)j modelises au moyen de structures 
elementaires en langage de type HLL (notees B_PORT) et en langage de 
type HDL, (notees A_PORT). 

Le systeme Configurateur est agence pour selectionner 

10 automatiquement les adaptateurs d'interface pour un modele compose. Le 
systeme Configurateur examine la liste d'adaptateurs d'interface utilisables 
pour un modele compose donne decrit par les proprietes du modele, et 
choisit le modele d'adaptateur d'interface dont les connexions physiques 
avec le reste du modele global sont en conformite avec la table des regies de 

15 coherence de connexions (TRCOH). Cette approche permet une rapide 
adaptation a de nouveaux types d'interfaces en ajoutant de nouveaux 
adaptateurs. 

II est important de souligner qu'un meme composant peut aussi bien 
etre modelise par une structure elementaire, ou composee, suivant son 
2 0 niveau de description. 

Un composant adaptateur d'interface peut etre partage entre plusieurs 
modeles composes connectes sur le meme port. Un seul d'entre ces 
modeles est autorise a emettre des signaux sur le port, les autres modeles 
etant purement observateurs. Une utilisation typique concerne les blocs de 
2 5 Monitoring et Verification qui n'envoient pas de signaux en sortie. Le partage 
des adaptateurs d'interface accelere la simulation par la simplification et la 
factorisation des parties du modele. 

On appellera par la suite Sondes, les adaptateurs d'interface servant a 
observer les signaux pour le compte des Blocs de Monitoring ou de 
30 Verification qui sont des Modeles Composes. 

Le systeme Configurateur est congu pour optimiser I'utilisation des 
Sondes en minimisant leur nombre. Comme la description des Composants 
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etablit la notion d'equivalence entre certains Composants, le systeme 
Configurateur essaye d'abord de partager le port d'un "Composant actif. Si 
cela s'avere impossible, il instancie tin composant Sonde adequat 
connectable sur I'interface de type HDL a partir d'une liste fournie dans la 
5 description du Composant Monitoring ou Verification. 

La partie ci-apres decrit les definitions relatives aux connexions entre 
Composants. Les notions d'interface et de port servent de support a la 
description des connexions entre les composants. 

10 Nous rappelons que le port est une selection arbitraire des signaux de 

I'interface de type HDL d'un composant, realisee a Taide des expressions 
regulieres portant sur les noms de ces signaux. Un signal donne peut 
appartenir a un ou plusieurs ports. La definition de chaque port est constitute 
de paires de type expression reguliere et expression de substitution 

15 correspondante. Ces expressions sont appliquees successivement au nom 
de chaque signal de I'interface et, en cas d'adequation 'match', I'expression 
de substitution est appliquee et le nom ainsi obtenu passe au traitement de la 
substitution suivante. Si la substitution finale donne un resultat final identique 
pour deux signaux, ces derniers seront connectes ensemble. Le 

2 0 configurateur genere un nom unique pour la connexion et place les 
informations adequates dans la table de cablage (TCAB). La methode decrite 
permet d'exprimer des regies complexes de connexion entre deux 
composants. Par exemple on peut connecter des signaux de noms differents, 
ou creer des regies de connexion des signaux d'entree avec les signaux de 

2 5 sortie. 

La creation de cette methode de definition par les interfaces et les 
ports permet un decouplage entre les declarations de modules de type HDL 
et les specifications de connexions pour le systeme Configurateur. Ce 
dernier combine ces deux sources d'information pour generer les 

3 0 connexions. Dans la majorite des cas, les modifications de declarations dans 

les parties de type HDL, tres frequentes pendant le developpement, 
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rTentrament pas de modifications dans les expressions regulieres decrivant 
les cablages. 

Dans I'exemple de mise en oeuvre de invention traite ci-apres, seules 
les connexions point a point sont traitees. Les connexions de type "bus" sont 
5 facilement modelisables en utilisant un composant a plusieurs sorties 
englobant le bus. 



Nous allons decrire ci-apres le procede de connexion automatique 
entre les "composants" par le systeme Configurateur pour constituer le 
10 modele global de simulation. Ce procede comprend les etapes suivantes : 

- Lecture du fichier de description d'architecture (FDARCH) du 
modele global et memorisation, dans une table de composants et 
de regies de connexion, dans une table de regies de coherence de 
connexions et dans une table de formatage de fichiers source, des 

15 informations relatives a ('ensemble des configurations possibles, 

chaque composant obtenant un nom identifiant, de fagon non 
equivoque, sa position dans I'architecture, ainsi qu'un type parmi 
plusieurs types (Composants actifs, Blocs de Monitoring et de 
Verification, Blocs intermediates, Blocs systemes et Blocs 

20 Globaux). 

Instanciation des composants, specifies dans le fichier de definition 
de configuration par I'utilisateur-concepteur au moyen d'une liste 
de composants presents designes par leurs nom et type et 
comportant des parametres ou faisant appel a des procedures, le 

2 5 fichier de definition de la configuration comprenant un fichier de 

selection des composants et de leur type et des indications 
supplementaires optionnelles concernant le type d'interface et le 
serveur concerne par la configuration a generer par le 
Configurateur, et memorisation des informations correspondantes 

30 dans une table de connexion des instances. 

- Connexion topologique des instances selon le schema defini par la 
table de composants et de regies de connexions (TCRC). 
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Lecture et memorisation des sources de type HDL des modeles 
instancies pour en extraire les noms et types des signaux 
d'interfaces. 

Cablage des signaux d'interface au niveau de chaque instance des 
composants par application d'expressions regulieres, stockees 
dans la table de composants et de regies de connexions (TCRC), 
et portant sur le nom des signaux constituant la table de cablage 
(TCAB). 

Utilisation de la table de connexion des instances (TCINST), de la 
table de cablage (TCAB) et de la table de formatage (TFMT) pour 
generer automatiquement les fichiers source de type HDL 
(MGHDL) et de type HLL (MGHLL) du modele global de simulation 
correspondant a la configuration specifiee par le fichier de 
configuration (FCONF). 

Le deroulement de la phase topologique est le suivant : 
Les Composants explicites specifies dans le fichier de 
configuration (FCONF) sont instancies en premier par le systeme 
Configurateur et places dans la table de connexion des instances 
(TCINST). Cette table contient le descriptif de chaque instance 
(label, type), accompagne de la liste des composants avec 
lesquels il est connecte. 

Ensuite, les Blocs Intermediates, specifies explicitement sur les 
ports des "Composants actifs" dans le fichier de configuration, sont 
instancies et ajoutes dans la table de connexion des instances 
(TCINST). 

Les connexions entre les composants actifs instancies sont 
comparees avec les regies contenues dans la table de coherence 
de connexions (TRCOH) pour detecter des incompatibilites entre 
les extremites des connexions entre les composants et, dans ce 
dernier cas, pour choisir et ajouter, dans la table de connexion des 
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instances (TCINST), un composant adaptateur (Bloc Intermediate) 
a inserer dans la connexion consideree. 

- Ensuite sont instancies les composants de type Bloc de Monitoring 
et Bloc de Verification. Le systeme Configurateur analyse les 

5 connexions des composants a modele compose et cherche des 

adaptateurs d'interface partageables au niveau des ports commun 
(voir modeles C_Portj sur la Figure 3). S'il n'existe pas de 
composant approprie pour partager la connexion en observation 
des signaux requis, un composant adaptateur d'interface aux 
10 proprietes specifiees par la description sera instancie par le 

configurateur. La table de connexion des instances (TCINST) est 
remise a jour. 

- Enfin, les composants 'bloc systeme' sont instancies et places 
dans la table de connexion des instances (TCINST), pour les 

15 composants qui en ont besoin. 

En phase de Cablage, le systeme Configurateur connecte les signaux 
d'interface au niveau de chaque port par application d'expressions regulieres 
portant sur les noms des signaux comme decrit dans la definition du port. 
2 0 Ces expressions sont appliquees aux noms des signaux extraits a partir des 
descriptions de type HDL des composants, de telle sorte que les 
changements des interfaces de type HDL d'une version de modele a I'autre 
n'influent pas directement sur les specifications des connexions entre les 
blocs. Cette phase genere comme resultat la table de cablage (TCAB) 

2 5 associant les signaux connectes ensemble, au nom unique du fil les 

connectant. Un certain nombre de verifications sont alors possibles, portant 
par exemple sur les connexions sans source, ou la connexion de plusieurs 
sorties ou autres. 

3 0 Les differentes etapes de la phase de cablage sont les suivantes : 
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- Les Composants Globaux et Blocs Systeme sont cables en 
premier a tous les composants. 

Ensuite sont cables les signaux entre les autres composants. 

- A la fin du cablage, une passe supplemental permet de 
connecter les signaux d'un composant non connectes dans les 
phases precedentes de cablage a des signaux du bloc systeme 
correspondants, specialement prevus pour forcer des valeurs 
connues et stables inhibant les ports non utilises. Les signaux 
concernes des blocs systeme portent un marquage special (par 
exemple un prefixe special dans le nom) pour ne pas etre 
connectes au cours des phases de cablage precedentes. 

En phase de generation des sources, le systeme Configurateur 
genere les fichiers source de type HDL et de type HLL en s'appuyant sur le 
contenu de la table de connexion des instances (TCINST), de la table de 
cablage (TCAB) et de la table de formatage (TFMT) pour generer 
automatiquement les fichiers source de type HDL (MGHDL) et de type HLL 
(MGHLL) du modele global de simulation correspondant a la configuration 
specifiee par le fichier de configuration (FCONF). 

Le fichier source de type HDL contient une description de la partie de 
type HDL (par exemple en VERILOG) du modele global de simulation 
correspondant au fichier de configuration (FCONF). En particulier, il contient 
I'instanciation de tous les modeles de type HDL des composants explicites 
dans le fichier de configuration, les blocs intermediates, Blocs Systeme et 
les Bloc Globaux ainsi que tous les fils reliant ces instances. 

Le fichier source de type HLL contient le programme correspondant a 
I'instanciation de tous les composants possedant une partie de leur modele 
en langage de type HLL. Dans le cas de langages HLL orientes objet, le 
code contient les constructeurs d'objets de classes HLL avec les parametres 
correspondants specifies dans la description de chaque composant. Un 
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tableau de formatage (TFMT) specifique a chaque projet permet la 
generation du code de type HLL approprie. 

Nous allons decrire le fichier de description d'architecture 
(FDARCH) pour une implementation specifique du systeme configurateur 
5 (PROGCONF) en langage PERL, choisi a cause de la manipulation directe 
des expressions regulieres et des tables associatives a plusieurs niveaux. 

L'architecture, representee sur la figure 1, est constitute d'un 
processeur (CPU) communicant par une passerelle (BRIDGE) avec une 
memoire systeme (MEMORY) et des entrees sorties (I/O). 

10 Le fichier FDARCH represents a ete decoupe pour faciliter son 

ecriture et sa manipulation en plusieurs parties presentees dans les annexes 
A1 a A5. Ce fichier definit l'architecture du modele global de simulation 
correspondant au schema generique represents sur la figure 1. Le langage 
de type HDL genere est VERILOG et le langage de haut niveau (HLL) 

15 genere est le C++. 

Les proprietes des Composants (type, Interfaces de type HDL, ports, 
constructeurs d'objets de la classe C++, etc..) sont decrites dans plusieurs 
tables ecrites en langage PERL. La correspondance entre ces tables et le 
diagramme illustrant le systeme Configurateur de la figure 2 est representee 

2 0 sur la figure 6. Dans la suite de la description, toutes les notations 
commengant par "%..." correspondent a des tables de hachage. 

Ces tables peuvent contenir la description, soit sous forme de suites 
de parametres, soit sous forme de references a des procedures qui generent 
les valeurs requises. 

2 5 Les procedures font partie de la description et sont changees pour 

chaque projet. L'exemple typique de leur utilisation est la generation 
d'interconnexion entre les composants. Souvent, le tableau correspondant a 
toutes les interconnexions possibles serait trap grand et difficile a generer et 
maintenir. En revanche une procedure peut etre tres compacte. 

3 0 La description des regies d'interconnexion des composants (TCRC) 

contient des parametres globaux communs a tous les types de composants. 



26 



Elle peut se presenter sous forme cTau moins une table. Dans le mode de 
realisation de la figure 6, elle se presente sous forme de sept tables 
associatives (hachages), dont trois ont pour entrees (%lnstNameModuleMap, 
%SysConnectMap, %SysSpecMap) les noms designant I'ensemble des 
modeles possibles pour un meme composant : 

- La table "%lnstNameModuleMap" (cf. 2 de A1), qui figure dans le 
fichier patent_config_defs.pm, pour decrire les Composants explicites. 
Cette table represente les regies de generation de connexion entre les 
signaux. Elle a pour entrees Connect et SelfConnect. 

- La table "%SysConnectMap" qui figure dans le fichier 
patent_Sysconfig_defs.pm pour les Blocs Systeme. 

- La table M %SysSpecMap" (cf. 4 de A2) qui figure dans le fichier 
patent_Sysconfig_defs.pm pour les Blocs Intermediaires. 

Les deux tables de hachage %SysWrapMap et %SysPinConst (cf. 6 de A2) 
contiennent les regies de connexion niveau systeme. La table de hachage 
%Activity_TypeMap associe le nom d'un composant avec son type. La table 
de hachage %PortProbeMap a pour entrees les noms des modules de type 
HDL utilisee dans la description des composants. 

Le systeme Configurateur est pilote par au moins une table de regies 
de coherence de connexions (TRCOH) qui represente les regies 
d'interconnexion entre les composants et d'insertion des composants 
intermediaires. Dans le mode de realisation de la figure 6, les regies de 
coherence de connexions sont reparties sous forme des deux tables 
suivantes : 

• %HwfConnectivityMap (cf. 2 de A2) 

• %HwifAlternateMap 

Le systeme Configurateur est pilote par au moins une table de 
formatage de fichiers source (TFMT) qui represente les regies de generation 
des instances des objets de type HLL. Dans le mode de realisation de la 
figure 6, les regies de generation des instances des objets de type HLL sont 
reparties sous forme des deux tables suivantes : 
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• %moduIeToCppClassMap (cf. 1 de A5) 
. %classCppProtoMap (cf. 2 de A5) 
Le role de chacune de ces tables de hachage est detaille ci-apres. 

Parmi les entrees definies pour les tables %lnstNameModuleMap, 
%SysConnectMap, %SysSpecMap, certaines sont obligatoires : 

- L'entree "MatchExpr", dont la valeur est I'expression reguliere qui 
permet d'accepter un nom (label) du composant dans le fichier de 
configuration, est utilisee pour definir les variantes de positions 
autorisees pour le composant. 

- L'entree "ExtrExpr", dont la valeur est I'expression reguliere qui assure 
I'extraction des parametres numeriques a partir du nom (label), est 
utilisee pour I'instanciation des Blocs Intermediates ou des Blocs 
Systeme ou pour generer le label du composant implicite. 

D'autres parametres sont facultatifs et peuvent etre ajoutes a la 
description des tables mais ces parametres ne peuvent etre utilises que par 
le code fourni avec la description - parmi eux : 

- NumAdd est un parametre auxiliaire servant de modificateur pour les 
parametres extraits par ExtrExpr, exploite par la procedure GenDest 
(voir ci-apres). 

- BaseldExpr est une expression reguliere qui permet de retrouver le 
composant actif correspondant a un composant intermediate ou 
systeme en cas d'ambiguTte. 

Les entrees suivantes du hachage definissent le Type du composant 
tel que, par exemple, DUT (modele de type HDL), XACTOR (transactor), ou 
autres. 

A chaque Type de Composant, correspond un hachage compose a 
son tour des entrees suivantes : 

- L'entree "Req Module" - contient le nom du module de type HDL 
(VERILOG) du composant et le nom du fichier source correspondant. 



28 



- L'entree "Connect" - est la definition de la methode de selection des 
signaux faisant partie d'un Port. Cette description est composee d'une 
suite d'entres indexes par le nom du Port. A chaque nom de Port on 
associe un tableau d'expressions regulieres et un pointeur sur une 
procedure de connexion des signaux qui gere I'application de ces 
expressions aux noms des signaux de I'interface du composant. 

Le Configurateur dispose de plusieurs procedures preprogrammees mais 
d'autres peuvent etre ajoutees et referencees. Les procedures 
preprogrammees acceptent des modificateurs : 

E (exclusif - le signal ne sera utilise qu'une seule fois) 
T(derivation - le signal peut etre utilise par plusieurs destinations). 
Une valeur speciale 'filter_out_wire_name\ attribue a un signal ou 
un groupe de signaux permet d'eliminer toute connexion sur les 
signaux correspondants. 

- L'entree "SelfConnect" - similaire a l'entree "Connect" contient les 
definitions des connexions des signaux de Ports qui peuvent etre 
connectes entre deux instances d'un meme composant - cette definition 
facilite la connexion de signaux unidirectionnels sortie -> entree dans le 
cas particulier de connexion tete-beche. 

L'entree "Port" - fournit la definition de I'ensemble des ports. C'est un 
hachage qui associe le nom de chaque port a un tableau comportant les 
elements suivants : 

. Le nom logique du composant de type HDL. 

• Le nom du module de type HDL ou un choix de modules. 

Le numero du port (utile pour la generations du code VERILOG et 
C++). 

- L'entree "GenDest" (cf. 1 de A3) - est un pointeur sur la procedure 
qui, pour un composant designe par un label et type, genere, pour 
chaque port, le label du composant auquel il se connecte. La 
procedure referencee doit etre imperativement specifiee par 
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I'utilisateur - cette procedure est egalement utilisee pour controler la 
coherence de la configuration demandee 

L'entree "SysConn" - est un hachage qui associe a chaque module de 
type HDL contenu dans le modele un pointeur sur la procedure de 
selection et nommage des Blocs Systeme. La procedure referencee 
doit etre imperativement specifiee par I'utilisateur. 

L'entree "GenHDLInstParam" - est un pointeur sur la procedure qui 
genere les parametres supplementaires requis par le simulateur de 
type HDL pour le code genere qui instancie la partie de type HDL du 
composant. 

L'entree "CfgCpp" - definit les parametres du constructeur de I'objet 
pour le code C++ d'identification de la Configuration, genere 
automatiquement, servant de filtrage pour la selection des 
Composants par le systeme Configurateur : 

Le premier parametre est le nom de la classe de I'objet C++ - c'est 
un nom predefini associe a celui du modele de type HDL - il est 
suivi par les tableaux correspondants a des groupes de 
parametres associes typiquement a chaque port du composant. Le 
mot-cle "Own" indique un composant a modele elementaire. 
• Ensuite viennent le nom du composant de type HDL reference 
dans la partie Port et I'identifiant de type du composant tels, par 
exemple, DUT, modele du circuit en projet; XACTOR, transacteur. 
Pour les blocs a modele compose, la partie parametres est plus 
riche : 

-> Elle contient le mot cle "Src" pour les composants actifs ou 
"Mon ' pour les composants de Verification et Monitoring 

^ Viennent ensuite les parametres du composant adaptateur 
d'interface, comprenant : 

le nom du composant de type HDL. 

Tidentifiant du type du composant et sa classe suivie du 
nom du port correspondant. 
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Ces derniers parametres sont specifies pour chaque port du 
bloc compose. 

Dans le code C++ genere pour un modele compose, les parametres 
5 transmis au constructeur d'une classe correspondent aux pointeurs sur les 
instances des adaptateurs d'interface. 

Tous ces parametres servent a guider le generateur du code C++ qui 
les combine avec les regies contenues dans le tableau de hachage 
M %classCppProtoMap" 

10 - L'entree "ProbeConnect" - associe a chaque port d'un composant 
Moniteur ou Verifieur la classe C++ acceptable comme adaptateur 
d'interface. Ainsi le Configurateur est capable d'optimiser le code en 
utilisant le meme adaptateur d'interface pour plusieurs composants 
(modele compose). 

15 - L'entree "SysWrap" - est un hachage qui pour chaque partie de type 

HDL d'un composant definit I'expression reguliere a utiliser pour 
mettre a un etat connu les signaux restes non connectes apres le 
cablage entre les composants. 

L'algorithme de connexion de deux composants est le suivant : 
Le systeme Configurateur essaye d'abord la connexion directe. 
Si celle-ci s'avere impossible d'apres la premiere table de hachage 
%HwfConnectivityMap, les modules specifies dans 
%HwifAlternateMap sont pris en compte pour etre places dans le 
composant. Les modules a choix sont indiques par le caractere ">" 
au debut de leur nom dans la specification d'un composant. 
A la fin, si aucun module ne convient, le systeme Configurateur revient 
au hachage %HwfConnectivityMap pour choisir les blocs 
intermediates a placer entre les composants. 
Si aucun bloc adequat n'est trouve une erreur est signalee. 
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L'utilisateur peut influencer les choix du systeme Configurateur en 
specifiant explicitement dans le fichier de configuration les blocs 
intermediates a connecter a un composant. 

Le tableau "%HwfConnectivityMap M permet a la fois la Verification de 
5 connectivity et la specification de Blocs intermediaires a inserer pour 
connecter deux Composants dont les ports ne sont pas directement 
connectables. 

Pour que deux blocs puissent etre connectes entre eux, il faut que 
%HwfConnectivityMap contienne des entrees qui decrivent les proprietes de 
10 cette connexion : 

-A chaque composant, on associe le composant auquel il peut etre 
connecte. 

- Une connexion directe est indiquee par la valeur "Direct". 
-Pour les connexions necessitant un Bloc intermediate, le nom de ce 
15 bloc est indique. 

-Pour certains blocs, la connectivity peut etre specifiee differemment 
pour chaque port du bloc. Cela sert a lever TambiguTte sur les 
connexions d'un bloc. Une utilisation typique concerne I'insertion de 
deux blocs intermediaires connectes tete-beche entre deux 
2 0 composants explicites. 

On souligne que la connectivity est exprimee ici de maniere globale, 
sans specifier les noms de signaux a connecter. 

Les Composants decrits en langage de type HLL peuvent posseder 
plusieurs implementations possibles des modules de type HDL A_Portj au 
2 5 niveau de chaque port i (voir Figure 3). La table de hachage 
"%HwifAlternateMap" specifie le choix possible pour chaque module de type 
HDL d'un composant Le systeme configurateur utilise cette information pour 
ne placer les blocs intermediaires qu'en cas de stricte necessity. 

30 Le hachage %SysWrapMap definit, pour chaque implementation d'un 

composant, son Bloc Systeme. Les entrees sont des noms de modules de 
type HDL associes avec le nom du bloc systeme et son implementation de 
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type HDL. Ces informations sont utilisees par le systeme Configurateur pour 
instancier le bloc systeme adequat a partir de specifications contenues dans 
le hachage %SysConnectMap (cf. 3 de A2). 

Le hachage %SysPinConst associe a chaque Bloc Systeme, les 
5 connexions de certains signaux de son interface aux noms des signaux 
(wires) correspondants au niveau systeme. Ces connexions sont 
independantes des configurations et ne sont pas regies par les expressions 
regulieres applicables lors du cablage des autres signaux. 

Typiquement, les signaux concernes sont des signaux d'horloge, de 
10 remise a zero (reset), etc... Les noms references sont declares dans un code 
de type HDL, specifique pour chaque modele en projet (design), et fournis 
par I'utilisateur (sous forme d'une variable ou d'un fichier) avec les 
descriptions des composants et des regies de connexion specifiques. 

Ce code specifique de type HDL est inclus systematiquement au 
15 debut du code de type HDL genere par le systeme Configurateur. 

La procedure "&gen_sys_VloglnstParameter M est une procedure qui 
genere les parametres d'instantiation pour le generateur du code de type 
HDL a partir du label et du type de chaque Composant. 

Le hachage %Activity_TypeMap (cf. 1 de A1) associe le nom d'un 
2 0 composant avec son type specifie par un mot cle: 
'actor' pour les composants actifs. 
'spectator* pour les blocs de Monitoring, 
'checker' pour les blocs de Verification. 

'helper' pour les blocs Systeme ou les blocs Intermediate en cas 
2 5 de connexion indirecte. 

La table "%PortProbeMap" est un hachage dont les entrees sont les 
noms des modules de type HDL utilises dans la description des composants. 
Les valeurs sont a leur tour des hachages qui associent, a chaque nom de 
port, un tableau contenant le nom de bloc pouvant servir de Sonde pour 
30 observer les signaux de ce port et le nom de la classe C++ correspondante. 
Ce hachage informe le systeme Configurateur sur le type de Composant 
capable d'observer les signaux d'un port donne et le type d'API C++ pouvant 
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etre utilisee pour analyser le flux de controle et de donnees observe sur ce 
port. 

La procedure &GenDest accepte en entree le label du composant 
source, son type et son port. Le resultat retourne est un hachage qui associe 
5 le label du composant cible connecte avec son port. 

Pour controler la coherence de la configuration generee quel que soit 
I'ordre de prise en compte des Composants, le systeme Configurateur 
appelle la procedure &GenDest avec les parametres obtenus pour le 
composant cible utilise comme source et verifie que le resultat correspond 
10 bien au composant et port source initial. 

Le systeme Configurateur appelle la procedure &GenDest pour 
chaque composant contenu dans le fichier de configuration en parcourant 
tous ces ports. 

Le hachage retourne par &GenDest peut contenir plusieurs 
15 composants avec leurs ports respectifs. C'est le cas notamment des 
connexions de type " bus " - &GenDest retourne tous les composants 
connectes par les bus sauf celui qui est donne en argument. Le systeme 
Configurateur insere automatiquement le composant « bus » necessaire. 

Le hachage %moduleToCppClassMap est un accelerateur de 
2 0 recherche permettant de retrouver la classe C++ a partir du nom de module 
de type HDL - il ne s'applique qu'aux Modeles elementaires (voir 1.14). 

Le hachage %classCppProtoMap decrit la generation des 
constructeurs d'objets de classes C++. Chaque entree correspond au nom 
d'une classe C++. Chaque description est un hachage compose de quatre 
2 5 entrees : 

- L'entree "Prea" correspond a la generation de la premiere partie du 
constructeur (classe nom de I'instance, premiers parametres). 

- L'entree "Iter" correspond a la partie iterative des parametres du 
constructeur. Cette regie est appliquee pour chaque element contenu 

30 dans l'entree CfgCpp de la description du composant. 
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- L'entree "Post" correspond a la partie finale du constructeur (derniers 
parametres parenthese fermante). 

- L'entree "Idle" est une regie de substitution pour la regie "Iter" pour les 
connexions non existantes (configurations partielles). Typiquement, un 
pointeur nul ou une chame nulle est genere(e). 

Chaque entree est une chame de caracteres contenant des selecteurs 
speciaux predetermines, substitues par les valeurs calculees par le systeme 
Configurateur. Ces selecteurs ont la forme generate #<Src|Dst|Act><ltem># 
ou 'Src', 'Dst' et 'Act' indiquent ('instance a prendre en compte , cette 
derniere etant transmise comme parametre a un constructeur d'un objet 
HLL : 

- 'Src' indique I'instance courante. 

- 'Dst' instance connectee a I'autre extremite du port. 

- 'Act' indique I'instance composee correspondant au 
Composant Actif contenant le port d'observation. 

<ltem> est un mot-cle indiquant la selection : 

- Inst' pour le nom d'instance cpp. 

- 'lid' pour le label de composant correspondant a Inst. 

- let' pour le type de composant (DUT, VERIFIER, XACTOR, 
Monitor...). 

- 'Port' pour le nom du port. 

Les deux variables "$cpp_preamble M (cf. 3 de A5), "$cpp_postambr f 
(cf. 4 de A5) contiennent respectivement le debut et la fin du texte de 
programme C++ genere par le systeme Configurateur. Le texte genere a 
partir du tableau %classCppProtoMap est insere au milieu. 

Les deux variables n $top_verilog_preamble" et 
"$topjverilog__postamble M contiennent respectivement le debut et la fin du 
texte de I'instance 'top' de la description de type HDL (VERILOG) de la 
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configuration. Typiquement, ce sont les instanciations des blocs d'horloge et 
autres blocs niveau systeme. 

La description qui suit est un exemple simple de generation de 
5 Configuration par la mise en oeuvre du systeme Configurateur qui est 
illustree dans le cas simplifie ci-apres de I'architecture d'un Systeme 
constitue d'un pont (BRIDGE) reliant une unite centrale (CPU), une Memoire 
et une carte entree/sortie (I/O). ^Architecture du Systeme est representee 
sur la figure 1. 

10 Dans cet exemple, le CPU et le BRIDGE peuvent etre modelises, soit 

par un modele VERILOG du projet "Design" (DUT, DUT_Core), soit par un 
modele compose C++ (XACTOR). 

L'interface entre le CPU et le BRIDGE est nommee FBUS. Plusieurs 
variantes de cette interface sont considerees correspondant a des etapes 
1 5 successives de developpement. 

Le bloc global Clock assure la distribution des signaux d'horloge et 
signaux systeme globalement pour I'ensemble des Composants 

Le systeme Configurateur s'appuie sur la description des Interfaces de 
type HDL des Composants. Des interfaces simples, ecrites en langage 
2 0 VERILOG, sont proposees ci-dessous a titre d'illustration pour chacun des 
Composants. Le systeme Configurateur n'analyse que cette partie des 
fichiers source contenus dans la bibliotheque des fichiers sources de type 
HDL (BFSHDL). Ms s'inscrivent dans une methodologie de prise en compte 
progressive de variantes de modeles au fur et a mesure de leur disponibilite. 

2 5 La description de type HDL des Interfaces qui suit est reduite a ce qui 

est necessaire a Illustration des possibilites et du fonctionnement du 
configurateur. Dans une situation reelle sont indues les descriptions des 
comportements comme dans le cas du modele de I'horloge (module 
CLOCK). 

30 La description est la suivante : 
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CPU : 

a) Le modele DUT de composant CPU (figure 7a) presente un port FBUS 
de connexion avec le BRIDGE ainsi qu'un ensemble de signaux 
Systeme definis ci-apres. 

module cpu ( 

XXadr_dat, 
XXreq, 
XXack, 
// 

elk, 
reset, 

powergood 

); 

inout [63:0] XXadr_dat; 
inout [3:0] XXreq; 
inout [3:0] XXack; 

input elk; 
input reset; 
input powergood; 

endmodule 

b) Le modele XACTOR (figure 7b) consiste en un modele abstrait C++ 
dont (Instance de type HDL est constitute de celle du Port nomme 
fbus__p. Dans cet exemple, il est suppose que le Port FBUS presente 
une variante nommee FBUSA dans laquelle les signaux 
bidirectionnels adr_dat ont ete eclates en paires de signaux 
unidirectionnels in (inXXadrjdat) et out (outXXadr_dat). 

module fbus__p ( 

inXXadr_dat, 

outXXadr_dat, 

inXXreq, 

outXXreq, 

inXXack, 

outXXack, 

// 

elk, 
reset, 

powergood 
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); 

input [63:0] inXXadr_dat; 
output [63:0] outXXadr_dat; 
input [3:0] inXXreq; 
output [3:0] outXXreq; 
input [3:0] inXXack; 
output [3:0] outXXack; 

input elk; 
input reset; 
input powergood; 

endmodule 



c) Le modele MONITOR du composant CPU est un modele compose 
permettant le Monitoring de Tinterface FBUS. Dans le cas ou il n'existe 
pas d'adaptateur de port fbus_p dans la configuration, une sonde 
contenant I'instance fbus__probe sera generee (figure 7c). 



module fbus_probe ( 
XXadr_dat, 
XXreq, 
XXack, 
// 

elk, 
reset, 

powergood 

); 

input [63:0] XXadr_dat; 
input [3:0] XXreq; 
input [3:0] XXack; 

input elk; 
input reset; 
input powergood; 

endmodule 



Bloc intermediaires d'adaptation FBUS : 
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Ces blocs realisent I'adaptation d'interface au niveau FBUS dans le 
cas ou la correspondance point a point des signaux est impossible. Le port 
FBUSA est la variante de FBUS dans laquelle les signaux bidirectionnels ont 
ete eclates en paires de signaux unidirectionnels d'entree (in) et de sortie 
5 (out). 

Le modele fbus_xchg (figure 7d) realise I'adaptation entre I'interface 
FBUS du port fbus_p et celui d'un port FBUSA - la largeur de I'interface peut 
etre parametree de facon a rendre compte devolutions technologiques 
possibles. 

10 

module fbus_xchg ( 

XXadr_dat, 

XXreq, 

XXack, 
15 // 

inXXadr_dat, 

outXXadr_dat, 

inXXreq, 

outXXreq, 
20 inXXack, 

outXXack 

); 

inout [63:0] XXadr_dat; 
inout [3:0] XXreq; 

2 5 inout [3:0] XXack; 

// 

input [63:0] inXXadr_dat; 
output [63:0] outXXadr_dat; 
input [3:0] inXXreq; 

3 0 output [3:0] outXXreq; 

input [3:0] inXXack; 
output [3:0] outXXack; 

// model body 

35 

endmodule 



- BRIDGE : 

a) Le modele DUT du composant BRIDGE (figure 7e) presente les trois 
4 0 ports respectifs vers les modeles CPU, MEM et IO ainsi que les 
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signaux Systeme delivres par le bloc systeme dedie SYS_BRIDGE et 
par le bloc global CLOCK. 

module bridge ( 
5 XXadr_dat, 

XXreq, 
XXack, 
YYadr, 
YYdata, 

10 ZZdata, 

ZZreq, 
ZZack, 
YYctrl, 
clk_2xp, 

15 clk_2xn, 

clkp, 
clkn, 
reset, 

powergood 
20 ); 

inout [63:0] XXadr_dat; 
inout [3:0] XXack; 
inout [3:0] XXreq; 

2 5 output [31:0] YYadr; 

inout [63:0] YYdata; 
output [2:0] YYctrl; 

inout [15:0] ZZdata; 

3 0 input [1:0] ZZack; 

output [1:0] ZZreq; 

input clk_2xp; 

input clk_2xn; 

35 input clkp; 

input clkn; 

input reset; 

input powergood; 

4 0 endmodule 

b) Le modele BRIDGE_CORE (figure 7f) est la variante DUT_CORE du 
composant BRIDGE presentant une interface FBUSA. Ce modele 
traduit la situation ou le modele du contr6leur d'interface FBUS n'est 
4 5 pas disponible. 
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module bridge_core ( 
inXXadr_dat, 
outXXadr_dat, 
inXXreq, 
outXXreq, 
inXXack, 
outXXack, 
// 

YYadr, 

YYdata, 

YYctrl, 

// 

ZZdata, 
ZZreq, 
ZZack, 
// 

clk_2xp, 

clk_2xn, 

clkp, 

clkn, 

reset, 

powergood 

); 

input [63:0] inXXadr_dat; 
output [63:0] outXXadr_dat; 
input [3:0] inXXreq; 
output [3:0] outXXreq; 
input [3:0] inXXack; 
output [3:0] outXXack; 

output [31 :0] YYadr; 
inout [63:0] YYdata; 
output [2:0] YYctrl; 

inout [15:0] ZZdata; 
input [1:0] ZZack; 
output [1:0] ZZreq; 

input clk_2xp; 

input clk_2xn; 

input clkp; 

input clkn; 

input reset; 

input powergood; 
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endmodule 



c) Le modele sys_bridge (figure 7g) est le block systeme dedie aux 
signaux Systeme du modele Bridge - il est directement alimente par le 
bloc CLOCK. 
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module sys_bridge( 
clk_2xp, 
clk_2xn, 
clkp, 
clkn, 
reset, 

powergood, 

// 

sys_CLK_2X, 
sys_CLK, 
sys_RESET, 
sys_POWER_GOOD 

); 

output clk_2xp; 

output clk_2xn; 

output clkp; 

output clkn; 

input sys__CLK_2X; 

input sys_CLK; 

input sysJRESET; 

input sys_POWER_GOOD; 

output reset; 

output powergood; 

clk_2xp = sys_CLK_2X; 

clk_2xn = -sys_CLK_2X; 

clkp = sys_CLK; 

clkn = ~sys_CLK; 

reset = sys_RESET; 

powergood = sys_POWER_GOOD; 

endmodule 

d) Le modele XACTOR (figure 7h) est un modele abstrait C++ dont 
('instance de type HDL est constitute de celle des differents ports 
respectivement fbus_p, cmem_p et cio_p vers CPU, MEM et IO. 
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module cmem_p ( 
YYadr, 
YYdata, 
YYctrl, 
elk, 
reset, 

powergood 

); 

output [31:0] YYadr; 
inout [63:0] YYdata; 
output [2:0] YYctrl; 

input elk; 
input reset; 
input powergood; 

endmodule 

module cio_p ( 
ZZdata, 
ZZreq, 
ZZack, 

// 

elk, 
reset, 

powergood 

); 

inout [1 5:0] ZZdata; 
input [1:0] ZZack; 
output [1:0] ZZreq; 

input elk; 
input reset; 
input powergood; 

endmodule 
MEMORY : 

Le modele DUT du composant MEMORY (figure 7i) presente les ports 
respectifs vers les modeles BRIDGE et CLOCK. 

modele DUT : 

module cmem ( 
YYadr, 
YYdata, 
YYctrl, 
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elk, 
reset, 

powergood 

); 

input [31:0]YYadr; 
inout [63:0] YYdata; 
input [2:0]YYctrl; 

input elk; 
input reset; 
input powergood; 

endmodule 

I/O : 

Le modele DUT du composant I/O (figure 7j) presente les ports respectifs 
vers les modeles BRIDGE et CLOCK. 

modele DUT : 

module cio ( 
ZZdata, 
ZZreq, 
ZZack, 

elk, 
reset, 

powergood 

); 

inout [15:0] ZZdata; 
output [1:0] ZZack; 
input [1:0] ZZreq; 

input elk; 
input reset; 
input powergood; 

endmodule 

Block Systeme global : 
Ce modele (figure 7k) assure la fourniture des signaux Systeme 
alimentant les blocs systeme dedies a chaque composant. 

module Clock ( 

sys_POWER_GOOD, 
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sys_RESET, 

sys_CLK, 

sys_CLK_2X 

); 

5 output sys_POWER_GOOD; 

output sys_RESET; 
output sys_CLK; 
output sys_CLK_2X; 

10 parameter HALF_PERIOD = 75; // 7.5ns, 66MHz 

parameter RESET_DELAY = 10000000000 ; // 1 .0ms 
parameter POWER_GOOD_DELAY = 5000000000 ; // 0.5ms 
initial begin; 

sys_POWER_GOOD = 0; 
15 sys_ RESET = 0; 

sys_CLK = 0; 
sys_CLK_2X = 0; 

#POWER_GOOD_DELAY sys_POWER_GOOD = 1 ; 
#RESET_DELAY sys_RESET = 1 ; 

20 end 

always begin 

#HALF_PERIOD sys_CLK = ~sys_CLK; 
end 

25 always @(posedge sys_CLK_2X) begin 

sys_CLK = ~sys_CLK; 
end 

endmodule 

30 



Definition des configurations : 



Les variantes de configuration marquent les differentes etapes de 
35 verification suivant la disponibilite des modeles — le systeme Configurateur 
elabore les configurations de facon non ambigue a partir des informations 
topologiques contenues dans le fichier de configuration. 
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La premiere configuration est definie par le fichier de configuration 1 
ci-apres et representee figure 8a : les modeles DUT du CPU et du BRIDGE 
ne sont pas disponibles. 
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Fichierde configuration 1 : 

CPU_0 XACTOR 

CPU_0 MONITOR 

BRIDGE_0 XACTOR 

5 CMEM_0 DUT 

CIO 0 DUT 



Le XACTOR CPU partage le port fbus_p avec le MONITOR. 



10 La deuxieme configuration est definie par le fichier de configuration 2 

ci-apres et representee figure 8b. 

Le BRIDGE XACTOR est connecte au CPU XACTOR par une 
interface de type FBUSA specifiee dans le fichier de configuration par 
I'attribut FBUSA=FBUS_xchg - le systeme Configurateur insere 
15 automatiquement le deuxieme adaptateurfbus_xchg 102. 



Fichier de configuration 2 : 

CPU_0 XACTOR FBUSA=FBUS_xchg 

CPU_0 MONITOR 

2 0 BRIDGE_0 XACTOR 

CMEM_0 DUT 

CIO 0 DUT 



2 5 Le XACTOR CPU partage le port fbus_p avec le Monitor. 

La troisieme configuration est definie par le fichier de configuration 3 
ci-apres et representee figure 8c : le BRIDGE DUT_CORE est connecte au 
CPU XACTOR par une interface de type FBUSA specifiee dans le fichier de 
30 configuration par I'attribut FBUSA=FBUS_xchg - le systeme Configurateur 
insere automatiquement le deuxieme adaptateur fbus_xchg 102. 

Fichier de configuration 3 : 

CPU_0 XACTOR FBUSA=FBUS_xchg 
35 CPU_0 MONITOR 

BRIDGE 0 DUT CORE 
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CMEM_0 
CIO 0 



DUT 
DUT 



Le XACTOR CPU partage le port fbus_p avec le MONITOR. 



La quatrieme configuration est definie par le fichier de configuration 4 
ci-apres et representee figure 8d : le modele CPU DUT est connecte avec le 
modele BRIDGE XACTOR - le systeme Configurateur insere 
automatiquement un adaptateur d'interface fbus pour realiser la connexion 
10 entre le CPU DUT et le BRIDGE XACTOR sans mention explicite de ce bloc 
dans le fichier de configuration. 



Le Configurateur instancie automatiquement la Sonde fbus_probe pour 
permettre I'observation de I'interface FBUS par le Monitor. 

La cinquieme configuration est definie par le fichier de configuration 5 
2 5 ci-apres et representee figure 8e : tous les modeles DUT sont disponibles. 



Fichier de configuration 4 : 



CPU_0 DUT 
CPU_0 MONITOR 
BRIDGE 0 XACTOR 



CMEM_0 DUT 
CIO 0 DUT 
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Fichier de configuration 5 : 



CPU 0 DUT 



CPU 0 MONITOR 
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BRIDGE_0 DUT 
CMEM_0 DUT 
CIO 0 DUT 



Le systeme Configurateur instancie automatiquement la Sonde 
3 5 fbus_probe pour permettre I'observation de I'interface FBUS par le Monitor. 
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La sixieme configuration est definie par le fichier de configuration 6 ci- 
apres et representee par la figure 8f : c'est une Configuration Multi-serveur - 
la Configl est repartie entre les 2 serveurs SERVER1 et SERVER2, la 
coupure se faisant au niveau de I'interface FBUS. 

5 

Fichier de configuration 6 : 

CPU_0 XACTOR SERVER1 
CPUJ) MONITOR SERVER1 
BRIDGE_0 XACTOR SERVER2 
10 CMEM_0 DUT SERVER2 

CIO_0 DUT SERVER2 

Les regies de connectivity permettant la generation des tables de 
connectives et de toute configuration pour cet exemple sont decrites en 
15 langage PERL dans les annexes A1 a A5. 

L'annexe A1 decrit, dans le cas de I'exemple choisi, les regies 
topologiques liees aux composants actifs a utiliser par le systeme 
Configurateur. 

2 0 L'annexe A2 decrit les regies topologiques liees aux Blocs systemes 

et aux Blocs intermediates a utiliser par le systeme Configurateur. 

L'annexe A3 decrit les procedures de connexion des Composants a 
utiliser par le systeme Configurateur. 

L'annexe A4 decrit le code de generation du fichier en langage de type 

2 5 HDL (Verilog_top.v) de connexion des composants a utiliser par le systeme 

Configurateur. 

L'annexe A5 decrit le code de generation des Classes C++. 
Les annexes A6 et A7 decrivent les fichiers resultats generes par le 
systeme Configurateur respectivement en langage bas niveau de type HDL 

3 0 (VERILOG) et en langage haut niveau (C++) pour constituer le modele de la 

configuration definie par la troisieme configuration correspondant a la figure 
8c. Le configurateur peut ainsi, avec I'utilisateur-developpeur, realiser son 
modele selon la variante de configuration choisie. 
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On aurait pu, de la meme fagon, illustrer les autres variantes de 
realisation du modele (figures 8a, 8b et 8d a 8f) qui pourraient etre traitees 
par le systeme Configurateur pour produire les fichiers resultats 
correspondants, constituant les modeles de simulation de I'architecture 
5 systeme envisagee pour le circuit integre en developpement. 

La figure 2 represente les divers moyens mis en oeuvre par un 
systeme informatique 40 mettant en oeuvre le procede de I'invention. 

Le calculateur 40 comporte une unite centrale 41, comprenant des 
circuits de traitement de donnees 42 (unite de traitement arithmetique ALU et 
10 memoires de programmes associes, globalement appeles, par la suite, ALU, 
par commodite), et comporte diverses memoires, de programmes ou fichiers 
de donnees d'exploitation, associees a I'unite centrale 41 . 

L'unite centrale 41 comporte une memoire 51 contenant la table de 
composants et de regies de connexions (TCRC), la table de regies de 
15 coherence de connexions (TRCOH) et la table de formatage de fichiers 
source (TFMT). Ces tables sont creees a partir du fichier de description 
d'architecture (FDARCH). 

La memoire 51 contient aussi des programmes ou moteurs intelligents 
PROGCONF necessaires pour constituer le systeme Configurateur 
20 exploitable par I'ALU 42. 

Une memoire 53 contient la table de connexion des instances 
(TCINST) representant les instances des composants et leurs 
interconnexions mutuelles requises par la Configuration definie dans le 
fichier de configuration FCONF et conformes au regies contenues dans les 
2 5 tables TCRC et TRCOH. 

La memoire 53 contient aussi la table de cablage (TCAB) representant 
les connexions physiques (fils) entre les parties de type HDL des 
composants instancies a partir de la bibliotheque de fichiers sources de type 
HDL (BFSHDL). 

30 II en resulte les fichiers MGHDL et MGHLL representant 

respectivement les fichiers sources du modele global de simulation de type 
HDL (VERILOG ou VHDL) et de type HLL (C++) generes par le systeme 
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Configurateur, modele permettant la co-simulation d'un circuit ASIC dans son 
environnement de verification. 

La mise en ceuvre du procede de invention va maintenant etre 
exposee. 

Le procede d'etablissement automatique, au moyen du calculateur ou 
systeme de traitement de donnees 40, de modele de simulation d'une 
configuration de modeles de composants determines, mutuellement relies 
par des connexions d'inter-fonctionnement, pour constituer un modele global 
de simulation MGHDL / MGHLL d'un circuit ASIC dans son environnement 
de verification, comporte les etapes suivantes (cf. figure 2a) : 

- un operateur, eventuellement aide ou meme remplace par un 
calculateur, etablit le fichier de description d'architecture 
(FDARCH) decrivant les regies d'interconnexion entre les differents 
composants, les modeles pouvant etre utilises pour modeliser 
chacun de ces composants et les regies de formatage pour 
generer les fichiers source du modele resultant. 

- un operateur, eventuellement aide ou meme remplace par un 
calculateur, etablit la bibliotheque BFSHDL de fichiers source, de 
parties de type HDL de modeles de composants respectifs 
susceptibles d'etre utilises dans une configuration conformement 
au contenu du fichier FDARCH. 

- I'operateur etablit le fichier FCONF de configuration visee, 
identifiant les composants et les modeles voulus (cf. figure 2b). 

- Le systeme de traitement lit le fichier de description d'architecture 
(FDARCH) genere et genere et place en memoire les tables 
TCRC, TRCOH et TFMT a partir de FDARCH (cf. figure 2b). 

- Les diverses tables TCRC, TRCOH et TFMT etant rendues 
accessibles au systeme de traitement de donnees 40 (cf. figure 
2c), 



50 



le systeme de traitement de donnees 40 lit le fichier de la 
configuration visee FCONF pour identifier les composants et leurs 
modeles requis (cf. figure 2c), 

- il lit la table de composants et de regies de connexion pour 
instancier et placer dans la table de connexion des instances 
TCINST les composants requis (cf. figure 2c). 

- II lit la table de regies de coherence de connexions (TRCOH) pour 
verifier la connectivity physique entre modeles et inserer, le cas 
echeant, des composants intermediates. 

II lit dans la bibliotheque BFSHDL les fichiers source 
correspondants aux parties de type HDL des modeles de 
composants instancies dans la table TCINST pour engendrer la 
table TCAB de connexions physiques (fils) entre les modeles de 
composants (cf. figure 2c). 

- II applique les regies de formatage de la table TFMT au contenu 
des tables TCINST et TCAB et il genere les fichiers source finaux 
MGHDL/MGHLL de modele global de simulation correspondant a 
la configuration specifiee par le fichier de configuration (FCONF) 
(cf. figure 2d). 

Le fichier d'entree FCONF correspond done a une description du 
schema theorique du type de la figure 1, sans toutefois les modeles, qui sont 
ajoutes lors de I'elaboration des tables intermediates TCINST, TCAB 
descripteurs de configuration et de connexions, afin de fournir un modele 
global de simulation qui soit effectivement operationnel et qui, en outre, ici, 
permette une observation de signaux particuliers. 

Les diverses tables ci-dessus peuvent etre prealablement stockees 
dans le calculateur 40 ou bien avoir ete stockees dans une memoire externe 
que Ton relie au calculateur 40, eventuellement par un reseau de 
transmission de donnees pour qu'elles lui soient accessibles. 
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L'ALU 42 dispose alors de toutes les donnees de base necessaires 
aux tables outils TCRC, TRCOH, TFMT pour que le programme 
PROGCONF associe au systeme Configurateur, commande, a I'ALU 42, 
I'elaboration des fichiers finaux MGHDL/MGHLL (cf. figure 2d). 

5 

La table intermediate TCAB, des descripteurs de connexions 
physiques, generee ici a partir d'une description de type HDL, est, dans cet 
exemple, soumise a une verification, afin de detecter des erreurs manifestes, 
telles que I'existence d'entrees ou sorties non raccordees ou encore de 
10 sorties reliees en parallele, lorsqu'il s'agit de sorties classiques de type dit 
'totem', done autres que celles a collecteur ouvert ou a inhibition commandee 
(tri-state). 

En cas de modification du fichier de depart FCONF, les tables 
intermediates TCINST, TCAB et les fichiers finaux MGHDL/MGHLL peuvent 
15 ainsi etre redefinis a partir des fichiers sources de modeles et de fichier 
FDARCH. On evite ainsi des risques d'erreur. 

Dans cet exemple, I'ALU 42 genere un modele global de co-simulation 
en associant, a au moins un bloc fonctionnel, plusieurs modeles de 
2 0 specification fonctionnelle ecrits en langages de programmation de niveaux 
differents, ici de type HDL et C++. 

On congoit que la presente invention peut etre mise en oeuvre selon 
d'autres formes specifiques, sans sortir de son domaine duplication tel que 
25 revendique. Par consequent, la presente description detaillee doit etre 
consideree comme etant une simple illustration d'un cas particulier dans le 
cadre de I'invention et peut done etre modifiee sans sortir du domaine defini 
par les revendications jointes. 
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ANNEXE : Description du code Configurateur 
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15 



Al - Regies Topologiques liees aux Composants actifs 

# ! /usr/tri ton/bin/perl 

############################################################## 

################# 

# 

# Copyright (c) 2000 BULL - Worldwide Information Systems 

# All rights reserved 
# 

# Module name : patent_conf ig_def s . pm 

# Author : Andrzej Wozniak 
# 

############################################################## 
################# 



### 

%Ac t i vi ty_TypeMap 

( 

20 "XACTOR" 
"DUT" 

" DUT_CORE " 
"MONITOR" 
" IND_CON" 
25 "SYS CON" 



=> 
=> 
=> 
=> 
=> 
=> 



'actor" , 
'actor" , 
'actor" , 
'spectator" , 
'helper", 
•helper", 
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35 



40 
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################## 
% I n s tN ameMo du 1 eMap = 

################## 



( 



2 de Al 



liste des labels CPU acceptes 



####### 

"CPU" => 

####### 

{ "MatchExpr" => " A (CPU )(?:_[ 0-3 ]) \$ " , 

"ExtrExpr" => " A CPU_ ( [ 0-3 ] ) \$ " , 
#### 

" DUT" => 

{ "ReqModule" => { "cpu" => "cpu_model.v" 
}, 



expressions regulieres de connexion 



"Connect" => { FBUS => [\&subst infix, ["(XX.*)", 



"Port" 



=> { FBUS => [CPU_a, cpu, 0], }, 
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"genDest" => \&genDest, 

"SysConn" => { CPU_a => \@std_glob_con, 
>, 

"CfgCpp" => [CPU_Dut, [ ['Own', [CPU_a , DUT , ], 
['None'], ],],], | 

' CPU_a = nom logique 
cpu = nom de 1' instance Verilog generee 
0 = n° de port 

\&genDest = defin.it la procedure generant 
le genDest 
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20 



25 



30 



35 



"XACTOR" => 

{ "ReqModule" => { "fbus_p" => " f bus_port . v" , 



} , 



meme 


nom 


de 


connexion 


de 


part 


et 


d' autre 



"Connect" => { " FBUSA" => [ \&subst_inf ix, 

["in (.*)", "aa_con"], ["out (.*)", "bb_con"],], 



Connexion tete-beche 



"SelfConnect" => { " FBUSA" => [ \&subst_inf ix, 
["out (.*)", "aa_con"], ["in (.*)", "bb_con"],], 

}, 

"Port" => { FBUSA => [FBUS_p, fbus_p, 0], }, 

"genDest" => \&genDest, 

"SysConn" => { FBUS_p => \@std_glob_con, 
}, 

"CfgCpp" => [CPU_Xactor, [ ['Src', [FBUS_p , 
FBUS type, Fbus hwif ] , [FBUS] ] ] ], 



} , 

"MONITOR" => 

{ "ReqModule" => { "fbus_p" => " f bus_port . v" , 
40 }, 

"Connect" => { "FBUS" => [ \&subst_inf ix, 

["in (.*)", "aa_con"], ["out (.*)", "bb_con"],], 

}, 

45 "SelfConnect" => { "FBUS" => [ \&subst_inf ix, 

["out (.*)", "aa_con"], ["in(.*)", "bb_con"],], 

}, 

"Port" => { FBUS => [FBUS_p, fbus_p, 0], } 
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"genDest" => \&genDest, 

"SysConn" => { FBUS_p => \@std_glob_con, 
}, 

"ProbeConnect" => { FBUS => Fbus_hwif, 
5 } , 

"CfgCpp" => [CPU_Monitor, [ [ 1 Mon ' , [FBUS_p , 
FBUS_type, Fbus_hwif ] , [FBUS],],],], 

}, 

10 #### 

},### CPU 

###### 

"BRIDGE" => 
###### 
15 { 

"MatchExpr" => ,,A (BRIDGE )(?:_[ 0-1 ]) \$ " , 
"ExtrExpr" => " "BRI DGE_ ( [ 0-1 ] ) \$ " , 
#### 

"DUT" => 

20 { "ReqModule" => {"bridge" => "bridge_x . v" , 

} , 

"Connect" => { FBUS => [\&subst infix, ["(XX.*)", 



""],], 
25 ""],], 
""], ] , 



CMEM => [\&subst_inf ix, [ " ( YY . * ) " , 
CIO => [\&subst_inf ix, ["(ZZ.*)", 

}, 



30 "Port" => { FBUS => [BRD, bridge, 0], 

CMEM => [BRD, bridge, 1], 
CIO => [BRD, bridge, 2], 

}, 

35 "genDest" => \sgenDest, 

"SysConn" => { BRD => [ \&get SpecSys Inst , "E", 
[\&subst_inf ix, ["(-*)", ""],],], 
}, 

"CfgCpp" => [Bridge_Dut, [ ['Own', [BRD, DUT, ], 
40 ['None'], ], 

] , 

] , 

}, 
#### 

4 5 "DUT_CORE" => 

{ "ReqModule" => { "bridge_core" => "bridge_core . v" , 
}, 
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"Connect" => { FBUSA => [ \&subst_inf ix, 
["(XX.*)", ""] , ["in( . *) ", "aa_con"], ["out (.*)", 
"bb_con"] , ] , 

CMEM => [\&subst_inf ix, [ " ( Y Y . * ) " , 

5 ""],], 

CIO => [\&subst_inf ix, ["(ZZ.*)", 

""],], 

}, 

10 "Self Connect" => { " FBUSA" => [ \&subst_inf ix, 

["out (.*)", "aa_con"], ["in (.*)", "bb_con"],], 

"~ }, 

"Port" => { FBUSA => [BRD, bridge_core , 0], 
15 CMEM => [BRD, bridge_core, 1], 

CIO => [BRD, bridge_core, 2], 

}, 

"genDest" => \&genDest, 
20 "SysConn" => { BRD => [ \&getSpecSysInst , "E" , 

[\&subst_infix, ["(.*)", ""],],], 
}, 

"CfgCpp" => [Bridge_Dut, [ ['Own', [BRD, 
DUT_CORE, ], ['None'], ], 
25 ] , 

] , 

} , 

#### 
"XACTOR" => 

30 { "ReqModule" => { "fbus_p" => " f bus_port . v" , 

"cmem_p" => "cmem_port . v" , 
"cio_p" => "cio_port. v", 

}, 

"Connect" => { FBUSA => [ \&subst_inf ix, ["in(.*)", 
35 "aa_con"], ["out (.*)", "bb_con" ] , ] , 

CMEM => [\&subst_inf ix, ["(YY.*)", 

""],], 

CIO => [\&subst_inf ix, ["(ZZ.*)", 

""],], 
40 }, 

"SelfConnect" => { "FBUSA" => [ \&subst_inf ix, 
["out (.*)", "aa_con"], ["in (.*)", "bb_con"],], 
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Port" => { FBUSA => [FBUS_p, fbus_p, 0], 

CMEM => [CMEM_p, cmem_p, 1], 
CIO => [CIO_p, cio_p, 2], 
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}, 

"genDest" => \&genDest, 

"SysConn" => { FBUS_p => \@std_glob_con, 
CMEM_p => \@std_glob_con, 
CIO_p => \@std_glob_con, 

}/ 

"CfgCpp" => [Bridge_Xactor, [ ['Src', [FBUS_p, 
FBUS_type, Fbus_hwif ] , [FBUS] ], 

['Src', [CMEM_p, CMEM_type, 

Cmem_hwif], [CMEM] ], 

['Src', [CIO_p, CIO_type, 

Cio_hwif], [CIO] ], 

] , 

] , 

), 

}, 
#### 
###### 

"CIO" => 

###### 
{ 

"MatchExpr" => " A (CIO) (?:_[0— 1] ) \$" , 
"ExtrExpr" => " A CIO_ ( [ 0- 1 ] ) \$ " , 
#### 

"DUT" => 

{ "ReqModule" => { "cio" => "cio_model. v", 
}, 

"Connect" => { CIO => [ \&subst_inf ix, [" (ZZ.*) 

""] , ] , 

>, 

"Port" => { CIO => [CIOD, cio, 0], 
}, 

"genDest" => \&genDest, 
"SysConn" => { CIOD => \@std_glob_con , 
} , 

"CfgCpp" => [Cio_Dut, [ ['Own', ['Src', [CIOD, 
DUT,], [None] ],], 

] , 

] , 

}, 

#### 
"XACTOR" => 

{ "ReqModule" => { "cio_p" => "cio_model . v" , 
} , 
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"Connect" => { CIO => [ \&subst_inf ix, ["(ZZ.*)", 

' ] , ] , 



5 "Port" => { CIO => [CIOD, cio, 0], 

} , 

"genDest" => \&genDest, 
"SysConn" => { CIOD => \@std_glob_con, 
10 " }, 

"CfgCpp" => [Cio_Dut, [ ['Own', ['Src', [CIOD, 
DUT,], [None] ],], 

] , 

15 ] , 

}, 
), 

###### 

"CMEM" => 

20 ###### 
{ 

"MatchExpr" => " A ( CMEM) (?:_[ 0-1 ]) \$ " , 
"ExtrExpr" => " A CMEM_( [0 — 1] ) \$" , 
#### 

2 5 "DUT" => 

{ "ReqModule" => { "cmem" => "craem_model . v" , 
}, 

"Connect" => { CMEM => [ \&subst_inf ix, 
["(ZZ.*)", ""],], 

30 } , 

"Port" => { CMEM => [CMEMD, cmem, 0], 
}, 

35 "genDest" => \&genDest, 

"SysConn" => { CMEMD => \@std_glob_con, 
. }, ~ 

"CfgCpp" => [Cmem_Dut, [ ['Own', ['Src', [CMEMD, 
4 0 DUT, ] , [None] ] , ] , 

] , 

] , 

} , 

#### 

4 5 "XACTOR" => 

{ "ReqModule" => { "cmem_p" => "cmem_model . v" , 
}, 
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"Connect" => { CMEM => [\&subst_inf ix, [" (ZZ.*)", 

""],], 

>, 

5 "Port" => { CMEM => [ CMEMD, cmem, 0], 

} , 

"genDest" => \&genDest, 

"SysConn" => { CMEMD => \@ std_glob_con , 
10 } , 

"CfgCpp" => [Cmem_dut, [ ['Own', ['Src', [CMEMD, 
DUT,], [None] ],], 

] , 

] , 

15 }, 
} 
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%PortProbeMap = 

20 ( 

'cpu'=> { 

"FBUS" => ["FBUS_PROBE" , Fbus_hwif ], 
} , 

) ; 

25 ###### 

1; ### makes perl happy 
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ANNEXE 

A2 - Regies Topologiques liees aux Blocs systeme et blocs 

intermediaires 

# ! /usr/triton/bin/perl 
5 ######################################################### 
###################### 
# 

# Copyright (c) 2000 BULL - Worldwide Information 
Systems 

10 # All rights reserved 

# 

# Module name : patent_sys_conf ig_def s . pm 

# Author : Andr ze j Wozniak 
# 

15 # Description : tables for driving configuration 

# generation aux part 
# 

# Rev Date : $Date: 2001-03-06 19:11:20+01 $ 
# 

20 ######################################################### 
###################### 
######### 

$GlobSysInst = 'SysClock 1 ; 

$GlobSysInstModule = 'Clock' ; 
25 $GlobSysInstModuleSrc = ' patent_sys_glob . v ' ; 

# Factorisation de 1' expression commune a 1' ensemble des 
connexions aux Blocs Globaux 
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@std_glob_con = ( \&getGlobSysInst , "E", 
30 [ \&subst_inf ix, 

(?:clk) \ $", "sys_CLK_2X"] , 
[" A (?: reset) \$", "sys_RESET" ] , 
[ lfA (?:powergood) \$" / "sys_POWER_GOOD" ] , 
] , ) ; 



####### 



%Hwf Connect! vityMap = 

( 

"bridge" => { 

40 "cpu" => "Direct", 

"cmem" => "Direct", 

"cio" => "Direct", 

"fbus_p" => "fbus_xchg", 
"fbus_xchg" => { FBUS => 'Direct 1 , 

45 }, 
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"bridge_core" => { 

"cpu" => "fbus_xchg", 

"cmem" => "Direct", 
"cio" => "Direct", 

"fbus_p" => "Direct", 
"fbus_xchg" => { FBUSA => 'Direct', 
FBUS => 'fbus_xchg', 

}, 

}/ 



"fbus_p" => { 

"fbus_xchg" => { FBUSA => 'Direct', 
FBUS => 'fbus_xchg', 

>, 

15 "cpu" => "fbus_xchg", 

"fbus_p" => 'Direct', 

} , 

"cio" => { "cio_p" => 'Direct' }, 
20 "cmem" => { "cmem_p" => 'Direct' }, 

"fbus_xchg" => { "fbus_xchg" => { FBUS => 'Direct' }, 
"cpu" => { "fbus_xchg" => { FBUS => 'Direct' }, 

}, 

25 ) ; 

####### 

%Hwif Alter nateMap = 

( 

) ; 

30 ### 

%SysWrapMap = 

( 

bridge => [ BRI DGE_sys , sys_bridge ] , 

bridge_core => [ BRI DGE_sys , sys_bridge ] , 
35 ) ; 

####### 



%SysConnectMap = 3 de A2 

( 

40 ###### 

"$GlobSysInst" => 

###### 

{ "MatchExpr" => " A ( $GlobSysInst ) \$" , 
"ExtrExpr" => " A ( $GlobSysInst ) \$ " , 
45 #### 

"SYS_CON" => 

{"ReqModule" => { "$GlobSysInstModule" => 
"$GlobSysInstModuleSrc" , 

} , 
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"Connect" => { "Global" => [ \&subst_inf ix, 
["(.*)",""], ], 

}, 

} , 

5 }, #### $GlobSysInst 

###### 

"BRIDGE sys " => 

###### 

{ "MatchExpr" => " A ( ? : BRIDGE_ [ 0-3 ] _) (sys) \$", 

10 "ExtrExpr" => " A BRIDGE_( [0—3] ) sys\$", 

#### 

"SYS_C0N" => 
{ "ReqModule" => 

{ "sys_bridge" => " sys_bridge . v" , 
15 } , 

"Connect" => { BRIDGE_a => [\&subst_inf ix, 
["(.*>", ""],], 
} , 

20 "SysConn" => { BRIDGE_a => [ \ SgetGlobSys Inst , "E", 

[\&subst_infix, [ "sys_ ( . * ) " , ""],],], 
} , 

"SysWrap" => { BRI DGE_a => [ \&subst_inf ix, 
["syswrap_(.*)'\ ""],], 
25 } , 

#### 

# Construction des noms des Blocs Systemes dedies 
a un Composant et 

# verification de la connectivity des interfaces 
30 entre les Blocs Systeme et 

# leurs Composants dedies 
"getOwnDest" => \&getSpecSysOwn, 
"genVloglnst Parameter " => 

\&gen_sys_VlogInstParameter, \^ 
35 #### 



# Variables f aisant reference 
a un code generique comraun 
pour 1' ensemble des pro jets 



40 }, #### BRIDGE_sys 

) ; 
### 

%SysSpecMap = 

( 

45 ###### 

"FBUS_XCHG" => 

###### 

{ "MatchExpr" => " A (?:.* )(FBUS XCHG)\$", 
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"ExtrExpr" => " A (?:.*)([ 0-3 ]) _FBUS_XCHG\$ " , 
"BaselidExpr" => " A . * ( FBUS_XCHG ) \$ " , 
### 

"IND_CON" => 
5 { "ReqModule" => 

{"fbus_xchg" => "f bus_xchg . v" , 

), 

"Port" => { "FBUS" => ["FBUS_xchg", "fbus_xchg", 

10 0], 

" FBUSA" => ["FBUS_xchg", "fbus_xchg", 1], 
} , 

"Connect" => { "FBUS" => [ \&subst_inf ix, 
["(XX.*)", ""],], 
15 " FBUSA" => [\&subst_inf ix, ["in (.*)", 

"aa_con"], ["out (.*)", "bb_con"],], 
} , 

"SelfConnect" => { "FBUS" => [ \ &subst_inf ix , 
["(XX.*)", ""],], 
20 "FBUSA" => [\&subst_inf ix, 

["out (.*)", "aa_con"], ["in (.*)", "bb_con"],], 

} , 

"genOwn" => \&genOwnSysSpecMapGeneric, 

"getOwnDest" => \ SgetSpecSysOwn , 

25 

"CfgCpp" => [Fbus_Xchg, [ ['Own', [fbus_xchg, 
IND_CON, ], ['None'], ], 

] , 

J , 

30 }, 
}, 

###### 

' FBUS_PROBE • => 

###### 

35 { "MatchExpr" => " A ( . * ) ( FBUS_PROBE) \$ " , 

"ExtrExpr" => " A . * ? ( [ 0-3 ] ) . * FBUS_PROBE\$ " , 
"BaselidExpr" => " A ( . * ) _FBUS_PROBE\$ " , 
#### 

"PROBE" => 

40 { "ReqModule" => { "fbus_probe" => "f bus_probe . v" 

} , 

"Connect" => {"FBUS" => [ \ & subst_inf ix, ["(.*)", 
""], ], 

), 

4 5 "Port" => { "FBUS" => [ " FBUS_probe" , 

"fbus_probe", 0], 
}, 

"SysConn" => { "FBUS_probe" => \@std_glob_con, 
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10 



}, 

" genVlog Inst Parameter " => 
\&gen_sys_VlogInstParameter_Generic, 
}, 

), 

) ; 
### 

%indTypeCf tpMap = 

( . 

"FBUS_xchg" => M FBUS_XCHG M , 
"fbus_xchg" -> "FBUS_XCHG", 
) ; 
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15 



20 



25 



30 



### 

QsysGlobConnTab = 

( 

[ sys_RESET 
[ sys_POWER_GOOD 
[ sys_CLK 
[ sys_CLK_2X 
) ; 
### 

%SysPinConst = 



( 



reference pa r % Sy sPinGons t 



RESET ] , 

P0WERJ300D ] , 
CLK_33MHz ] , 

CLK 66MHz ] , 



"$GlobSysInst M => \ @ sysGlobConnTab, 
CPU_sys => \@sysGlobConnTab, 
CMEM_sys => \@ sysGlobConnTab , 
CI<0_sys => \@sysGlobConnTab, 
BRIDGE_sys => \@sysGlobConnTab, 
BRIDGE => \@sysGlobConnTab, 
) ; 
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##### 

sub gen_sys_VlogInstParameter { 

35 my($inst, $cat, $Cftp, $i_map) = @_; 

($Cftp, $i__map) = getCf tp ($inst ) unless $Cftp and 
$i_map; 

my($extr) = $ { $ i_map } { $Cf tp } { ' ExtrExpr 1 } ; 
$inst =~ $extr; 

40 my ( $Module_num, $Node_num, $SubNode_num) - ($1, $2, $3, 

$4); 

my ( $parent__inst , $parent__cf tp, $parent_map) = 
&get_parent_inst ($inst) ; 
my ( $num__add) = 0; 
4 5 $num_add = $ { $parent_map } { $parent_cf tp } { 1 NumAdd 1 } , 

$Node_num += $num_add 

if exists $ { $parent_map} { $parent_cf tp } { 'NumAdd' } ; 
my ( $parameter ) = ""; 
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foreach $pp ( $Module_num, $Node_num, $SubNode_num) { 
$parameter . = " , "if $parameter ne "" and $pp = - 
/\d+/; 

$parameter .= $pp if $pp = - /\d+/; 

5 } 

my ( $conn_mask) = 
&get_parent_inst_connected_mask ( $inst ) ; 
if ( $conn_mask ne ""){ 

$parameter . = " , "if $parameter ne ""; 
10 $parameter .= $conn_mask; 

} 

if ($parameter) { 

return 11 # ( $ parameter) " ; 

} 

15 return "" 

} 

####### 

1; ### makes perl happy 
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ANNEXE 

A3 - Procedures de connexion des Composants 

# ! /usr/triton/bin/perl 

######################################################### 
5 ###################### 
# 

# Copyright (c) 2000 BULL - Worldwide Information 
Systems 

# All rights reserved 
10 # 

# Module name : patent_connect_defs.pm 

# Author : Andrzej Wozniak 
# 

# Description : connection generation 
15 # 

# Revision : $Revision: 1.1 $ 
# 

# Rev Date : $Date: 2001-01-29 20:19:10+01 $ 
# 

2 0 ######################################################### 
###################### 
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#### 

sub genDest { 

25 my($inst, $extExpr, $srclfc) = @_; 

my (%dest ) = ( ) ; 
my ($df t) ; 

unless ( $inst =~ /$extExpr/ ) { 
&dprint__conf ig_error ( "genDest" , 
30 "number extracting expression \"$extExpr\" 

failed for $inst\n") ; 

return (\%dest, $dft) ; 

} 

while ( $inst /$extExpr/ ){ 

35 $nl = $1; 

$n2 = $2; 
$n3 = $3; 
my($nb) = 0; 

if($inst $InstNamelModuleMap{CPU} { "MatchExpr" } ) { 
40 ## CPU 

%dest = ("BRIDGE_$nl" => "FBUS"), 
$dft = "BRIDGE", 

last if $srclfc / A FBUS [A-Za-zO— 9_] */ ; 
goto label_error; 

45 } 

if($inst =- $ InstNameModuleMap { BRIDGE } { "MatchExpr" } ) { 
## BRIDGE 
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%dest = ( "CPU_$nl" => "FBUS"), 
$dft = "CPU" , 

last if $srclfc /FBUS/; 
%dest = ( "CMEM_$nl" => "CMEM"), 
5 $dft = "CMEM" , 

last if $srclfc =~ /CMEM/; 
%dest = ( "CIO_$nl" => "CIO"), 
$dft = "CIO", 
last if $srclfc /CIO/; 
10 goto label_error ; 

} 

if($inst $InstNameModuleMap{CMEM} { "MatchExpr" } ) { 
## CMEM 

%dest = ( "BRIDGE_$nl" => "CMEM"), 
15 $dft = "BRIDGE", 

last if $srclfc =~ /^CMEM$/; 
goto label_error ; 

} 

if($inst $InstNameModuleMap{CIO} { "MatchExpr" }) { 

20 ## CIO 

%dest = ( "BRI DGE_$nl " => "CIO"), 
$dft = "BRIDGE", 
last if $srclfc /^CIO$/; 
goto label_error; 

25 } 

&dprint_config_error ( "genDest" , "unknown instance 
$inst"); 
last ; 
label_error : 

30 &dprint_conf ig_error ( "genDest" , "unknown interface 

$srclfc for instance $inst"); 
last ; 

} 

return (\%dest, $dft); 
35 } 

####### 

1; ### makes perl happy 
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ANNEXE 

A4 — Code de generation du fichier Verilog Top.v de 

connexion des Composants 

#! /usr /triton/bin/perl 
5 ######################################################### 
###################### 
# 

# Copyright (c) 2000 BULL - Worldwide Information 
Systems 

10 # All rights reserved 

# 

# Module name : patent_verilog_def s . pm 

# Author : Andrzej Wozniak 
# 

15 # Description : VERILOG strings and defs 

# for generation of top.v source code 
# 

# Revision : $Revision: 1.4 $ 
# 

20 # Rev Date : $Date: 2001-02-19 19:55:41+01 $ 
# 

######################################################### 
###################### 



2 5 @verilog_src_path = 

( 

"$db_dir/patent/sim/models" , 

) 



30 $top_verilog_header = « " END_OF_TOP_HEADER " 

///////////////////////////////////////////////////////// 
///////////// 

// FILE \"%s\" GENERATED by A.W. PERL SCRIPT 
// FROM \"%s\" file 
35 ///////////////////////////////////////////////////////// 
/////////////\n\n 
////// 

'timescale lOOps 
END OF TOP HEADER 



$top_verilog_preamble = « " END_OF_TOP_PREAMBLE " 

////// 

module top ( ) ; 

45 

wire POWER_GOOD; 
wire RESET; 
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wire CLK_33MHz; 
wire CLK_66MHz; 

5 $GlobSysInstModule $GlobSysInst ( 

. sys_POWER_GOOD (POWER_GOOD) 

. sys_RESET (RESET) , 

. sys_CLK (CLK_33MHz) , 

. sys_CLK_2X (CLK_66MHz ) 
10 ); 
END_0 F_TOP_PREAMBLE 

#### 

15 $top__verilogj)ostamble = «"END_OF_TOP_POSTAMBLE" 

endmodule 

///////////// 
20 // END 

///////////// 

END OF TOP POSTAMBLE 



25 ####### 

1; ### makes perl happy 
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ANNEXE 

A5 - Code de generation des Classes C++ 

# ! /usr /t riton/bin/perl 

######################################################### 
5 ###################### 

# 

# Copyright (c) 2000 BULL - Worldwide Information 
Systems 

# All rights reserved 
10 # 

# Module name : patent_cpp_gen_def s . pm 

# Author : Andrzej- Wozniak 
# 

# Description : cpp generation tables 
15 # 

# Revision : $Revision: 1.1 $ 
# 

######################################################### 
###################### 

20 

#### 

%moduleToCpPRClassMap = 

( 

fbus_probe => Probe_hwif, 
25 ) ; 

#### 

%classCppProtoMap = 

( 

#### 

30 CPU_Dut => 

#### 
{ 

Prea => "static CPU_Dut #SrcInst# 
(LabelClass : : #SrcIid#, TypeClass : : #SrcIct#, \n" 
35 . "\t\t\t\tstring ( \"#SrcVlogPath#\" ) ) ;\n", 

}, 

#### 

CPU_Monitor => 
#### 
40 { 

Prea => "static CPU_Monitor #SrcInst# 
(LabelClass: :#SrcIid#", 

Iter => ", \n\t\t\t&#DstPort#", 
Post => " ) ; \n" , 
45 Idle => ", \n\t\t\t0", 

}, 

#### 
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Bridge_Dut => 

#### 

{ 

Prea => "static Bridge_Dut #SrcInst# 
5 (LabelClass : : #SrcIid#, TypeClass : : #SrcIct# , \n" 

. "\t\t\t\tstring ( \"#SrcVlogPath#\" ) ) ;\n", 

}, 

#### 

Cio_Dut => 
10 #### 
{ 

Prea => "static Cio_Dut #SrcInst# 
(LabelClass : : #SrcIid#, TypeClass : : #SrcIct#, \n" 

. "\t\t\t\tstring ( \" #SrcVlogPath# \ " ) ) ; \n", 

15 }, 

#### 

Cmem_Dut => 

#### 

{ 

20 Prea => "static Cmem_Dut #SrcInst# 

(LabelClass : : #SrcIid#, TypeClass : : #SrcIct#, \n" 

. "\t\t\t\tstring ( \" #SrcVlogPath#\ " ) ) ;\n", 

}, 

#### 

25 CPU_Xactor => 

#### 
{ 

Prea => "static CPU_Xactor #SrcInst# 
(LabelClass: :#SrcIid#", 
30 Iter => " , \n\t\t\t&#SrcPort#", 

Idle => ", \n\t\t\t0", 
Post => ") ; \n", 

>, 

#### 

35 Bridge_Xactor => 

.#### 
{ 

Prea => "static Bridge_Xactor #SrcInst# 
(LabelClass: :#SrcIid#", 
40 Iter => ", \n\t\t\t&#SrcPort#", 

Idle => ", \n\t\t\tO", 
Post => ") ;\n", 

}, 

#### 

45 Fbus_hwif => 

#### 
{ 
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Prea => "static Fbus_hwif #SrcInst# 
(LabelClass: : #SrcIid#, TypeClass: : #SrcIct#, \n" 

. "\t\t\t\tstring (\"#SrcVlogPath#\") ) ; \n", 

}, 

5 #### 

Probe_hwif => 

#### 

{ 

Prea => "static Probe_hwif #SrcInst# 
10 (LabelClass :: #SrcIid#, TypeClass :: PROBE, \n" 

. "\t\t\t\tstring (\"#SrcVlogPath#\") ) ;\n", 

} , 

#### 

Cmem_hwif => 
15 #### 
{ 

Prea => "static Cmem_hwif #SrcInst# 
(LabelClass: : #SrcIid#, TypeClass: : ftSrcIctt , \n" 

. "\t\t\t\tstring (\"#SrcVlogPath#\") ) ; \n", 

20 }, 

#### 

Cio_hwif => 

#### 

{ 

25 Prea => "static Cio_hwif #SrcInst# 

(LabelClass: : #SrcIid#, TypeClass: : #SrcIct#, \n" 

. "\t\t\t\tstring ( \"#SrcVlogPath# \ " ) ) ; \n", 

} , 

#### 

30 Fbus_Xchg => 

#### 
{ 

Prea => "static Fbus_Xchg #SrcInst# 
(LabelClass : : #SrcIid#, TypeClass : : #SrcIct# , \n" 
35 . "\t\t\t\tstring (\"#SrcVlogPath#\" ) ) ; \n", 

} , 
) ; 

##### 

$cpp_preamble = « " END_OF_P RE AMBLE " 

40 /////////////////////////////////////// 
// FILE GENERATED by A.W. PERL SCRIPT 
// FROM %s file 
// FOR %s 

////////////////////////////////////// An\n 
45 ///////////// 

#include \"server_registry . hpp\" 
#include \ " server_components . hpp\" 
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//////////// /\n\n 

const string ServerRegistry :: m_serverName = \"%s\"; 
const string ServerRegistry : : m_conf igName = \"%s\"; 
const int ServerRegistry: :m_serverNumber = %d; 
Status InstantiateConf igurat ion ( ) \{ 
/////////////An 
END OF PREAMBLE 



10 #### 

$cpp_j>ostamble = « 11 END_OF_JPOSTAMBLE 11 

\t return Success; \n } 
///////////// 
// END 
15 ///////////// 

END_OF_POSTAMBLE 

#### 

20 ####### 

1; ### makes perl happy 
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ANNEXE 

A6 — Fichier Resultat Verilog 



///////////////////////////////////////////////////////// 
5 ///////////// 

// FILE "config_server_pat03_top. v" GENERATED by A.W. 
PERL SCRIPT 

// FROM "patent/sim/conf igs/pat03 . cfg" file 
///////////////////////////////////////////////////////// 
10 ///////////// 



15 



20 



25 



30 



35 



40 



45 



////// 

N time scale 10 Ops 
////// 

module top ( ) ; 



wire 
wire 

wire 
wire 



POWER_GOOD; 
RESET; 

CLK_33MHz; 
CLK 66MHz; 



Clock SysClock( 

. sys_POWER_GOOD 
. sys_RESET 
. sys_CLK 
. sys_CLK_2X 

) ; 

//////////////////////////////// 
///// Wire Declaration Section 
//////////////////////////////// 



(POWER_GOOD) 
(RESET) , 
(CLK_33MHz) , 
(CLK 66MHz) 



// wire 
// wire 
// wire 
// wire 

wire 
output ( 1 ) 

wire 
output ( 1 ) 

wire 
output ( 1 ) 

wire 
output ( 1 ) 

wire 



CLK_33MHz; 
CLK_66MHz; 
P0WER_G00D; 
RESET; 



[3:0] 
[63 : 0] 
[3:0] 
[3:0] 
[63:0] 



input ( 1 ) output ( 1 ) 
wire [3:0] 

output ( 1 ) 
wire [3:0] 



Wl_00_inXXack; 
Wl_00_inXXadr_dat; 
Wl_00_inXXreq; 
Wl_00_outXXack; 
Wl_00_outXXadr_dat 
Wl_00_outXXreq; 
W 00 XXack; 



// output (1) 
// input (3) output (1) 
// input (3) output (1) 
// input (3) output (1) 

// input (1) 



// input (1) 
// input (1) 
// input (1) 
// 

// input (1) 
// inout(2) 
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wire 


[63:0] 


w 


00 


XXadr dat; 




// inc 


wire 


[3:0] 


w 


00 


_XXreq; 


// 


inout ( 2 ) 


wire 


r o -j . ni 
L 3 1 . U J 


w 


u u 


X I dUI , 


/ / 


input ( 1 ) 


output ( 1 ) 














wire 


[2:0] 


. W_ 


00 


_YYctrl; 


// 


input ( 1 ) 


output ( 1 ) 














wire 


[63:0] 


w 


00 


_YYdata; 


// 


inout (2) 


wire 


[1:0] 


w_ 


~oo] 


_ZZack; 


// 


input ( 1 ) 


output ( 1 ) 














wire 


[15:0] 


w 


00 


_ZZdata; 


// 


inout (2) 


wire 


[1:0] 




~- 00 \ 


_ZZreq; 


// 


input ( 1 ) 



output ( 1 ) 



//////////////////////////////// 





wire 




W_ 


00 


_clk 2xn; 


// 


input ( 1 ) output ( 1 ) 


15 


wire 




w_ 


"oo* 


_clk_2xp; 


// 


input ( 1 ) output ( 1 ) 




wire 




w 


"oo" 


_clkn; 


// 


input ( 1 ) output ( 1 ) 




wire 




w 


~ 00 ~ 


_clkp; 


// 


input ( 1 ) output ( 1 ) 




wire 


[3: 


0] 




W_00 inXXack; 




// 


input ( 1 ) 




output ( 1 ) 
















20 


wire 


[63 


:0] 




W_00_inXXadr_dat; 




// input (1) 




output ( 1 ) 


















wire 


[3: 


0] 




W_00_inXXreq; 




// 


input ( 1 ) 




output ( 1 ) 


















wire 


[3: 


0] 




W_00_outXXack; 






// input (1) 


25 


output ( 1 ) 


















wire 


[63 


:0] 




W_0 0_outXXadr_ 


dat ; 


// input (1) 




output ( 1 ) 


















wire 


[3: 


0] 




W_00_outXXreq; 






// input (1) 




output ( 1 ) 
















30 


wire 
output ( 1 ) 




w_ 


_00_ 


_powergood; 




// 


input ( 1 ) 




wire 




w_ 


_00_ 


_reset ; 


// 


input ( 1 ) output ( 1 ) 



//////////////////////////////// 



///// Module Instancies Section 
35 //////////////////////////////// 

//// BRIDGE_0_CPU_0_FBUS_XCHG -> IND_CON -> FBUS_xchg 
//////////// 

f bus_xchg BRI DGE_0_CPU_0_FBUS_XCHG ( 

40 ^ .XXadr_dat ~ ~ ( W_00_XXadr_dat ) , 

.XXreq (W_00_XXreq) , 

.XXack (W_00_XXack) , 

. inXXadr_dat (Wl_00_outXXadr_dat ) , 

. outXXadr__dat ( Wl_00_inXXadr_dat ) , 

45 .inXXreq"~ ( Wl_00_outXXreq) , 

.outXXreq ( Wl_00_inXXreq) , 

. inXXack ( Wl_00_outXXack) , 

.outXXack (Wl_00_inXXack) ) ; 
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//// CMEM_0 -> DUT -> CMEMD //////////// 
cmem CMEM_0 ( 

. YYadr 

. YYdata 

. YYctrl 

.elk 

. reset 

. powergood 



(W_ 
(W_ 
(W 



00_YYadr) , 
00_YYdata) , 
_00_YYctrl) , 
(CLK_66MHz) , 
(RESET) , 

(POWER GOOD) ) 



10 



15 



//// CIO_0 -> DUT -> CIOD //////////// 
cio CIO_0 ( 

. ZZdata 

. ZZreq 

. ZZack 

.elk 

. reset 

. powergood 



(W_00_ZZdata) , 
(W_00_ZZreq) , 
(W_00_ZZack) , 
(CLK_66MHz) , 
(RESET) , 

(POWER GOOD) ) ; 



20 



25 



//// BRIDGE_0 -> DUT_CORE -> 
bridge_core BRI DGE_0 

. inXXadr_dat 
. outXXadr__dat 
. inXXreq ~" (Wl_ 
. outXXreq 
.inXXack (Wl_ 
. outXXack 



BRD //////////// 
( 

(Wl_00_inXXadr_dat ) , 

(Wl_00_outXXadr__dat) , 
00_inXXreq) , 

(Wl_00_outXXreq) , 
00_inXXack) , 

(Wl_00_outXXack) , 



30 



35 



. YYadr 


(W_ 


00 


_YYadr) , 


. YYdata 


(W 


"oo" 


_YYdata) , 


. YYctrl 


(W 


"oo" 


_YYctrl) , 


. ZZdata 


(W 


"oo" 


_ZZdata) , 


. ZZreq 


(W_ 


"oo" 


_ZZreq) , 


. ZZack 


(W 


"oo" 


_ZZack) , 


. clk_2xp 


(W_ 


"oo" 


_clk_2xp) , 


. clk_2xn 


(W 


"oo" 


_clk_2xn) , 


. elkp 


(W 


"oo" 


_clkp) , 


. elkn 


(W 


"oo" 


_clkn) , 


. reset 


(W 


"oo" 


reset) , 



, powergood 



40 



(W_00_powergood) ) ; 
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//// CPU_0_BRIDGE_0_FBUS_XCHG -> IND_CON -> FBUS_xchg 
//////////// 

fbus_xchg CPU_0_BRI DGE_0_ 

. XXadr_dat 
.XXreq (W_00 
.XXack (W_00 
. inXXadr_dat 
. outXXadr dat 



dat ) 



FBUS_XCHG ( 
(W__00_XXadr_ 
_XXreq) , 
_XXack) , 

(W_00_outXXadr_dat) 
(W 00 inXXadr dat) , 
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. inXXreq 


(W_00_outXXreq) , 






. outXXreq 


(W_00_inXXreq) , 






. inXXack 


(W_00 outXXack) , 


5 




. outXXack 


(W_00_inXXack) ) ; 




//// CPU_0 


-> XACTOR -> 


FBUS_p //////////// 




f bus_p 


CPU_0_XACTOR_FBUS p ( 






. inXXadr dat 


(W_00_inXXadr dat) , 






. outXXadr_dat 


( W_00_outXXadr_dat ) 


10 




. inXXreq 


(W_00_inXXreq) , 






. outXXreq 


(W_00_outXXreq) , 






. inXXack 


(W_00_inXXack) , 






. outXXack 


(W_00_outXXack) , 






.elk 


(CLK 66MHz) , 


15 




. reset 


(RESET) , 






. powergood 


(POWER_GOOD) ) ; 




//// BRIDGE 


i 0 sys -> SYS 


CON -> BRIDGE sys /////, 




sys bridge 


#(0, 32 1 h00000007) BRIDGE 0 sys ( 


20 




.elk 2xp 


(W 00 elk 2xp) , 






. clk_2xn 


(W_00_clk_2xn) , 






. elkp 


(W 00 elkp) , 






. elkn 


(W_00_clkn) , 






. reset 


(W_00_reset) , 


25 




. powergood 


(W_00_powergood) , 






. sys_CLK_2X 


(CLK 66MHz) , 






. sys_CLK 


(CLK_33MHz) , 






. sys_RESET 


(RESET) , 






.sys POWER GOOD (POWER GOOD) ) ; 


30 










endmodule 








///////////// 






// END 






35 


///////////// 
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ANNEXE 

A7 - Fichiers resultat C++ 

/////////////////////////////////////// 
// FILE GENERATED by A.W. PERL SCRIPT 
5 // FROM patent /sim/conf igs/pat03 . cfg file 
// FOR server 

/////////////////////////////////////// 



10 ///////////// 

# include "server_registry . hpp" 
#include "server components . hpp T 



15 ///////////// 



const string ServerRegistry :: m_serverName = "SERVER"; 
const string ServerRegistry : : m_conf igName = "pat03"; 
20 const int ServerRegistry :: m_serverNumber = 1; 
Status InstantiateConf iguration ( ) { 
////////////// 

static Fbus_hwif CPU_0_XACTOR_FBUS_p ( LabelClass : : CPU_0 , 
25 TypeClass : : FBUS_type, 

string ( "top. CPU_0_XACTOR_FBUS_p" ) ); 
static Cio_Dut CIO_0 ( LabelClass :: CIO_0 , TypeClass :: DUT, 

string ( "top. CIO_0") ) ; 
static Cmem_Dut CMEM_0 ( LabelClass :: CMEM_0 , 
30 TypeClass : : DUT, 

string ( "top. CMEM_0" ) ) ; 
static Bridge_Dut BRIDGE_0 (LabelClass :: BRIDGE_0 , 
TypeClass: : DUT_CORE, 

string ( "top. BRIDGE_0") ) ; 
35 static CPU__Xactor CPU_0_XACTOR ( LabelClass :: CPU_0 , 
TypeClass: :XACTOR, 

&CPU_0_XACTOR_FBUS_p) ; 
static CPU_Monitor CPU_0__MONITOR (LabelClass :: CPU_0 , 
TypeClass: : MONITOR, 
4 0 &CPU_0_XACTOR_FBUS_p) ; 

static Fbus_Xchg BRI DGE_0_CPU_0_FBUS_XCHG 
(LabelClass : : BRI DGE_0_CPU_0 , TypeClass: : FBUS_XCHG, 

string ("top. BRI DGE_0__CPU_0_FBUS_XCHG" ) ) ; 
4 5 static Fbus_Xchg CPU__0_BRIDGE_0_FBUS_XCHG 

(LabelClass: : CPU__0__BRIDGE__0 , TypeClass: :FBUS_XCHG, 
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string ( "top. CPU_0_BRIDGE_0_FBUS_XCHG" ) ) ; 
return Success; 

} 

5 ///////////// 
// END 

///////////// 
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REVENDICATIONS 



1. Procede d'etablissement automatique, au moyen d'un systeme de 
traitement de donnees (40) associe a un programme dit Configurateur pour 
5 constituer un modele global de simulation d'une architecture comprenant des 
modeles de circuits integres en developpement pouvant constituer, a I'aide 
du Configurateur automatique, une machine ou une partie d'une machine et 
des modeles d'environnement de simulation, permettant de tester et de 
verifier le circuit en developpement, d'un fichier de definition de configuration 

10 (FCONF) de composants de 1'architecture, ces composants constituant des 
blocs fonctionnels determines de description des fonctionnalites de circuits 
integres ou de parties de circuits integres, les composants etant choisis par 
Tutilisateur dans une bibliotheque de differents types de composants et une 
bibliotheque de composants d'environnements pour constituer le modele 

15 global de 1'architecture repondant a la specification fonctionnelle definie dans 
le fichier de definition de configuration (FCONF) et conforme a la 
specification de I'architecture du modele global specifie par un fichier de 
description de I'architecture (FDARCH), procede caracterise par le fait qu'il 
comporte les etapes suivantes: 

2 0 - lecture du fichier de description d 'architecture (FDARCH) du 

modele global et memorisation, dans une table de composants et de regies 
de connexion (TCRC), dans une table de regies de coherence de connexions 
(TRCOH) et dans une table de formatage de fichiers source (TMFT), des 
informations relatives a I'ensemble des configurations possibles, chaque 

2 5 composant obtenant un nom (LABEL) identifiant, de fagon non equivoque, sa 
position dans I'architecture, ainsi qu'un type parmi plusieurs types 
(Composants actifs, Blocs de Monitoring et de Verification, Blocs 
intermediaires, Blocs systemes et Blocs Globaux), 

- instanciation des composants, specifies dans le fichier de 

30 definition de configuration (FCONF) par I'utilisateur-concepteur au moyen 
d'une liste de composants presents designes par leurs nom et type et 
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comportant des parametres ou faisant appel a des procedures, le fichier de 
definition de la configuration (FCONF) comprenant un fichier de selection des 
composants et de leur type et des indications supplementaires optionnelles 
concernant le type d'interface et le serveur concerne par la configuration a 
5 generer par le Configurateur, et memorisation des informations 
correspondantes dans une table de connexion des instances (TCINST), 

- connexion topologique des instances et memorisation des 
informations correspondantes dans une table de connexion des instances 
(TCINST), 

10 - connexion physique des signaux d'interface, au niveau de 

chaque instance des composants, par application d'expressions regulieres, 
memorisees dans la table de composants et de regies de connexion (TCRC) 
portant sur le nom des signaux constituant une table de cablage (TCAB), 

- utilisation de la table de connexion des instances (TCINST), de 
15 la table de cablage (TCAB) et de la table de formatage (TFMT) pour generer 

automatiquement des fichiers source de type HDL (MGHDL) et de type HLL 
(MGHLL) du modele global de simulation, correspondant a la configuration 
specifiee par le fichier de definition de configuration (FCONF). 

2. Procede selon la revendication 1, dans lequel le systeme 
2 0 Configurateur transmet aux parties de type HLL de chaque composant 

comprenant des informations sur : 

- le nom (LABEL) du composant, 

- le type de I'instance (DUT, XACTOR, VERIFIER, MONITOR), 

le chemin HDL, a savoir le nom hierarchique du composant dans la 

2 5 description du modele. 

3. Procede selon la revendication 1 ou 2, dans lequel le fichier de 
definition de la configuration (FCONF) comporte en plus un mot-cle 
(serveur<n>) indiquant le nom ou numero du serveur sur lequel se trouve 
instancie un composant dans le cas d'une utilisation du procede sur un 

3 0 systeme multi-serveur. 
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4. Procede selon la revendication 3, dans lequel, dans le cas d'une 
utilisation multiserveur, le systeme configurateur execute les etapes 
suivantes : 

- decoupage de la Configuration en plusieurs parties (de type 
5 HDL et de type HLL) en triant les composants de type HDL et 

les objets HLL selon leurs appartenances aux serveurs, 

- generation des composants de type HDL peripheriques servant 
a I'envoi et la reception des signaux entre les parties de la 
configuration, 

10 - duplication des Blocs Globaux par le systeme Configurateur et 

instanciation des Blocs Globaux dupliques sur chaque serveur, 

- generation des parties de type HLL servant de support de 
communication entre les serveurs. 

5. Procede selon la revendication 3 ou 4, dans lequel la connexion 
15 automatique entre les composants par le systeme Configurateur comprend 

plusieurs phases : 

- une phase topologique de haut niveau realisant la selection 
des composants et leurs positionnements respectifs, 

- une phase de cablage realisant la connexion effective entre 
2 0 les composants, cette phase generant comme resultat une 

table de cablage (TCAB) associant les signaux connectes 
ensemble, au nom unique du fil les connectant, 

- une phase de generation des fichiers sources de type HDL et 
de type HLL. 

2 5 6. Procede selon la revendication 5, dans lequel la phase de cablage 

est effectuee par le systeme Configurateur selon les trois etapes suivantes : 

a. les Blocs Globaux et les Blocs Systeme sont connectes en 
premier a tous les composants, 
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b. viennent ensuite les connexions des signaux entre les autres 
composants, 

c. a la fin du cablage, une passe supplemental permet de 
connecter les signaux restant non connectes de chaque composant a 

5 des signaux predetermines pour assurer un etat stable et determine, 

le systeme Configurateur generant alors des configurations partielles 
comprenant un sous-ensemble de 1'architecture. 

7. Procede selon la revendication 6, dans lequel les signaux 
predetermines sont les signaux du Bloc Systeme correspondant au 

10 composant. 

8. Procede selon une des revendications 1 a 7, dans lequel le fichier 
de description de I'architecture (FDARCH) du modele global comprend les 
modeles de simulation des Blocs globaux et des Blocs Systeme, ces deux 
types de composants etant connectes entre eux et gerant des signaux 

1 5 d'environnement. 

9. Procede selon la revendication 8, dans lequel les Blocs Systeme 
sont connectes aux autres composants et leur fournissent des signaux 
systeme qui leur sont specifiques. 

10. Procede selon la revendication 9, dans lequel le systeme de 
2 0 traitement de donnees (40) effectue un controle de conformite des 

connexions en comparant la table de connexion des instances (TCINST) 
reelles entre blocs avec la table de regies de coherence de connexions 
(TRCOH). 

11. Procede selon la revendication 10, dans lequel le systeme de 
2 5 traitement de donnees (40) compare les connexions physiques entre les 

composants a la table de regies de coherence de connexions (TRCOH), pour 
detecter des incompatibilites entre extremites de connexions entre les 
composants, et, en pareil cas, il specifie, et ajoute, dans la table de 
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connexion des instances (TCINST), un composant adaptateur (Bloc 
Intermediate) (101) insere dans la connexion consideree. 

12. Procede selon la revendication 11, dans lequel le fichier de 
definition de configuration (FCONF) comprend des informations, specifiees 

5 par un attribut, concernant I'utilisation de composants adaptateurs (Blocs 
intermediates) avec les instances des Composants actifs, dont les 
connexions sont comparees a la table de connexion des instances (TCINST), 
pour detecter des incompatibilites entre extremites de connexions entre les 
composants, et, en pareil cas, il specifie, et ajoute, dans la table de 
10 connexion des instances (TCINST), un autre composant adaptateur (Bloc 
intermediate) (102) insere dans la connexion consideree. 

13. Procede selon la revendication 12, dans lequel le systeme de 
traitement de donnees (40) selectionne certaines des connexions entre 
composants de la table de regies de coherence de connexions (TRCOH) et 

15 specifie, et ajoute, dans la table de connexion des instances (TCINST), des 
connexions supplementaires constituant des derivations aboutissant a des 
modeles supplementaires respectifs, representant des outils de surveillance 
(sondes) des connexions. 

14. Procede selon Tune des revendications 1 a 13, dans lequel, 
2 0 dans la phase de generation des fichiers sources, le systeme Configurateur 

genere les fichiers source en langage HDL (MGHDL) et en langage HLL 
(MGHLL) en s'appuyant sur le contenu de la table de composants et de 
regies de connexion (TCRC), la table de regies de coherence de connexions 
(TRCOH), la table de formatage des fichiers source (TMFT), la table de 
2 5 connexion des instances (TCINST) et la table de cablage (TCAB). 

15. Procede selon la revendication 14, dans lequel le systeme de 
traitement de donnees (40) effectue un traitement par le systeme 
Configurateur, pour chaque variante de configuration, pour obtenir plusieurs 
modeles de simulation correspondant a la meme specification fonctionnelle, 
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mais ecrits en une description comportant differents melanges des langages 
de niveaux differents (HDL, HLL). 

16. Procede selon Tune des revendications 1 a 15, dans lequel le 
systeme de traitement de donnees (40) etablit la specification fonctionnelle 

5 du modele global de simulations dans un format informatique compatible 
avec un langage de programmation de haut niveau (HLL) et en format 
compatible avec un langage de description du materiel (HDL). 

17. Procede selon une des revendications 15 ou 16, dans lequel le 
fichier de definition de configuration (FCONF) comprend, pour chaque 

10 composant, au moins une partie en langage de type HDL, ladite partie en 
langage de type HDL fournissant une interface vers d'autres modeles. 

18. Procede selon la revendication 17, dans lequel les modeles 
comprenant une partie en langage de type HLL comprennent des 
adaptateurs d'interface. 

15 19. Procede selon la revendication 18, dans lequel le systeme 

Configurateur choisit chaque modele d'adaptateurs d'interface en fonction de 
la table de regies de coherence de connexions (TRCOH). 

20. Procede selon la revendication 19, dans lequel les connexions 
des signaux physiques sont specifies par des "Ports"', chaque port etant une 

2 0 selection arbitraire des signaux de I'interface de type HDL d'un composant a 
I'aide des expressions regulieres portant sur les noms de ces signaux, et 
etant constitue de paires expression reguliere / expression de substitution, 
ces expression etant appliquees successivement au nom de chaque signal 
de I'interface de type HDL, et, si la substitution finale est identique pour deux 

2 5 signaux, ces derniers sont connectes entre eux, la connexion etant 
memorisee dans la table de cablage (TCAB). 
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21. Precede selon la revendication 20, dans lequel chaque adaptateur 
d'interface etant partage entre plusieurs modeles connectes sur le meme 
port, un seul de ces modeles emet des signaux sur ledit port. 

22. Systeme de traitement de donnees (40) pour I'etablissement 
5 automatique d'un modele global de simulation d'une configuration de blocs 

fonctionnels determines, mutuellement relies par des connexions 
d'interfonctionnement, pour constituer le modele global de simulation d'une 
architecture comprenant des modeles de circuit integres en developpement 
pouvant constituer une machine repondant a la specification fonctionnelle 

10 d'une configuration, systeme caracterise par le fait que le systeme de 
traitement de donnees (40) utilise un programme Configurateur 
(PROGCONF) qui comprend des moyens de realiser une simulation du 
cablage par I'application d'expressions regulieres memorisees, d'utiliser un 
fichier de definition de configuration (FCONF) en langage de haut niveau, 

15 une table de composants et de regies de connexion (TCRC) decrivant les 
proprietes (type, Interfaces de type HDL, ports, constructeurs d'objets de 
classes HLL, etc.) des composants logiciels de simulation du circuit, une 
table de regies de coherence de connexions (TRCOH) en langage de haut 
niveau (HLL), des moyens d'instancier les elements resultants du fichier de 

2 0 definition de configuration (FCONF), un generateur du code HLL qui combine 
les parametres des composants avec les regies de connexion. 

23. Systeme selon la revendication 22, caracterise en ce qu'il existe 
au moins cinq types de composants : les Composants actifs, les Blocs de 
Monitoring et Verification, les Blocs intermediates, les Blocs Systeme et les 

2 5 Blocs Globaux. 

24. Systeme selon la revendication 23, caracterise en ce que le 
systeme est agence pour effectuer un controle de conformite des connexions 
en comparant la table de connexion des instances (TCINST) avec une table 
de regies de coherence des connexions (TRCOH) physiques entre les 

30 modeles choisis des blocs constituant le modele global. 
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25. Systeme selon la revendication 24, caracterise en ce qu'il est 
agence pour comparer la table de connexion des instances (TCINST) reelles 
entre blocs a la table de coherence des connexions (TRCOH), pour detecter 
des incompatibilites entre extremites de connexions entre blocs, et, en pareil 

5 cas, pour specifier, et ajouter, dans la table de regies de coherence des 
connexions (TRCOH), un bloc fonctionnel adaptateur (Bloc Intermediate) 
(101) insere dans la connexion consideree. 

26. Systeme selon une des revendications 22 a 25, caracterise en ce 
que la table de composants et de regies de connexion (TCRC), comprenant 

10 les proprietes des composants, contient des parametres globaux communs a 
tous les types de composants et se presente sous forme d'une table repartie 
suivant une ou plusieurs tables, associatives ou non, dont les entrees sont 
des noms designant I'ensemble des modeles possibles pour un meme 
composant. 

15 27. Systeme selon la revendication 26, caracterise en ce que les 

tables associatives peuvent contenir la description, soit sous forme de suites 
de parametres, ou bien sous forme de references a des procedures qui 
generent les valeurs requises, les entrees de ces tables associatives etant 
des noms designant I'ensemble des modeles possibles pour un meme 

2 0 composant et formant une chaine de caracteres contenant des identificateurs 
speciaux predetermines, substitues par les valeurs calculees par le systeme 
Configurateur. 

28. Systeme selon la revendication 27, caracterise en ce qu'au moins 
trois selecteurs indiquent I'instance a prendre en compte, cette derniere etant 
25 transmise comme parametre a un constructeur d'un objet HLL : 

- un premier selecteur indique I'instance ("item") courante, 

- un deuxieme selecteur precise I'instance connectee a I'autre 
extremite du port, 
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- un troisieme selecteur indique I'instance composee 
correspondant au Composant actif contenant le port 
d'observation. 

29. Systeme selon Tune des revendications 22 a 28, caracterise en ce 
5 que le systeme Configurateur utilise une ou plusieurs tables de regies de 

coherence de connexions (TRCOH), qui represented les regies 
d'interconnexion entre les composants et d'insertion des composants 
intermediates, une ou plusieurs tables de composants et de regies de 
connexions (TCRC), qui represented les regies de connexion niveau 
10 systeme et les regies de generation de connexions entre les signaux, et une 
ou plusieurs tables de formatage de fichiers source (TFMT), qui represented 
les regies de generation des instances des objets de type HLL. 

30. Systeme selon Tune des revendications 22 a 29, caracterise en ce 
que le systeme Configurateur utilise : 

15 - une classe de base en HLL permettant d'identifier de fagon univoque 

chaque objet instancie et d'interroger la configuration, 

- des moyens de generation et d'instanciation automatique des Blocs 
Systeme, 

- des moyens des tableaux associant les signaux connectes ensemble 
2 0 au nom unique du filles connectant, 

- des moyens d'utiliser un tableau de formatage pour generer les 
fichiers sources en HDL et HLL. 

31. Systeme selon Tune des revendications 22 a 30, caracterise en ce 
que I'operateur specifie fonctionnellement, dans la plus large mesure 

2 5 possible, la configuration dans le langage de plus haut niveau et il complete 
la specification fonctionnelle par les composants en langage de plus bas 
niveau. 

32. Systeme selon une des revendications 22 a 31, caracterise en ce 
que les entrees suivantes du hachage definissent le Type du composant (par 
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exemple DUT (modele HDL), XACTOR (transactor), MONITOR, VERIFIER 
ou autres) et, a chaque Type de Composant, correspond un hachage 
compose a son tour des entrees suivantes : 

- une premiere entree ReaModule - contient le nom du module HDL 
5 du composant et le nom du fichier source correspondant, 

- une deuxieme entree Connect - est la definition de la methode de 
selection des signaux faisant partie d'un Port, cette description 
etant composee d'une suite d'entrees indexees par le nom du 
Port ; a chaque nom de Port, le configurateur associe un tableau 

10 d'expressions regulieres et un pointeur sur une procedure de 

connexion des signaux qui gere I'application de ces expressions 
aux noms des signaux de ['interface du composant. 

33. Systeme selon la revendication 32, caracterise en ce que la 
structure generique des Composants actifs comprend un Bloc contenant la 

15 description HDL et un Bloc en HLL, fournissant les chemins d'acces aux 
ressources HDL et, le cas echeant, une description du bloc en HLL, 
('ensemble des signaux du bloc HDL constituant I'interface du Bloc 
englobant, formee, d'une part, de Ports, qui sont des selections logiques 
arbitraires des signaux d'une interface et, d'autre part, d'adaptateurs 

2 0 d'interface qui sont les parties logicielles assurant, sur chaque Port, la 
communication bi-directionnelle entre les parties en HLL et celles en HDL, 
les adaptateurs d'interface etant choisis par le systeme Configurateur. 

34. Systeme selon la revendication 33, caracterise en ce que les Ports 
sont specifies sous forme d'expressions regulieres, qui servent a la fois a 

2 5 selectionner les sous-ensembles de signaux a connecter et a definir les 
regies de connexions. 

35. Systeme selon une des revendications 22 a 34, caracterise en ce 
que le systeme Configurateur genere des Composants dits de Transfert qui 
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sont inseres de chaque cote de la coupure sur les serveurs, ces composants 
etant simplement des fils pour les entrees et des registres pour les sorties. 



ABREGE 
Inventeurs : Andrzej WOZNIAK 
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La presente invention concerne un procede et un systeme 
5 d'etablissement d'un modele global de simulation d'une architecture. En 
particulier, I'invention concerne un procede d'etablissement automatique, au 
moyen d'un systeme de traitement de donnees (40) associe a un programme 
dit Configurateur pour constituer un modele global de simulation d'une 
architecture comprenant des modeles de circuits integres en developpement, 
10 procede caracterise par le fait qu'il comporte les etapes suivantes: 

- lecture du fichier de description d 'architecture (FDARCH) du 
modele global et memorisation des informations relatives a I'ensemble des 
configurations possibles, 

- instanciation des composants et memorisation des informations 
15 correspond antes dans une table de connexion des instances (TCINST), 

- connexion topologique des signaux d'interface, 

- generation automatique des fichiers source de type HDL 
(MGHDL) et de type HLL (MGHLL) du modele global de simulation, 
correspondant a la configuration specifiee par le fichier de definition de 

2 0 configuration (FCONF). 



Figure 2A 



